[Vm-dev] tty's hypothesis on configH in CMakeVMMaker

[Eliot Miranda]

On Mon, Jun 16, 2014 at 3:33 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> Yes, config.h is a leftover of old make process which i had to port over
> to cmake build process without need to do big changes in source code.
> I am strong opponent of idea that configuration variables shall
> automatically , dynamically and implicitly change depending on where you
> compiling the code. Configuration , as a whole can change, but not its
> variables.
> They must be defined once and stay same regardless of building environment.
>
> That gives you a better chances that software which you successfully built
> using same configuration will work identically no matter who or where is
> built it.
> And sure thing, for having variations, you can define own configuration
> e.g. MyVMWith(orWithout)UUID
> and use it to compile VM with that flag changed.
> But as i say, key here that this flag is set by your hand once and
> forever, not by some pre-build configure script which depends on where it
> runs on.
>

Depends what you're talking about.  In this case some linuxes have
/usr/include/uuid.h and a program called uuidgen, others have
/usr/include/uuid/uuid.h and a program called uuidgenerate (let alone other
unixes).  IMO it is not the business of a VM source generation pass to
decide this.  It is a compile-time configuration pass.

The approach of having lots of configurations determined at VM source
generation time leads to VM source which becomes obsolete, is inflexible,
is duplicated.  There needs to be a sensible split.  VM generation time is
not the time to choose things like sets of plugins, particular include file
locations.  IMO it should only produce a full suite of source.  A build
directory is the place to decide what plugins to choose etc, allowing
special configurations for special uses (an embedded device vs a desktop
OS, etc).  Compile time configuration is the time to choose include files,
library names etc, etc.


>
>
>
> On 15 June 2014 23:27, gettimothy <gettimothy at zoho.com> wrote:
>
>>
>> Hi Eliot.
>>
>>
>>
>> I have a theory on the Pharo CMakeVMaker configH method.
>>
>>
>> CogUnixConfig configH
>> " right now its like that "
>> ^ '
>> #ifndef __sq_config_h
>> #define __sq_config_h
>>
>> /* explicit image width */
>>
>> #define HAVE_INTERP_H 1
>>
>> ....
>>
>>
>>
>> based on my work getting the
>> oscogvm/platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c... to compile.
>> Working from the C source up to configuration then to Squeak....we start
>> with the source code for sqUnixUUID.c
>>
>> #include "config.h"
>>
>> #if defined(HAVE_SYS_UUID_H)
>> # include <sys/types.h>
>> # include <sys/uuid.h>
>> #elif defined(HAVE_UUID_UUID_H)
>> # include <uuid/uuid.h>
>> #elif defined(HAVE_UUID_H)
>> # include <uuid.h>
>> #else
>> # error cannot find a uuid.h to include
>> #endif
>>
>>
>> On my platform, I needed that HAVE_UUID_H define set.
>> To do that, I modified the acinclude.m4 file to check for the <uuid.h>
>> (my changes in Bold--I emailed you this previously)
>>
>>
>> AC_MSG_CHECKING([for UUID support uuid/uuid.h] and uuid_generate)
>> AC_TRY_COMPILE([#include <uuid/uuid.h>],[uuid_generate;],[
>> AC_MSG_RESULT(yes)
>> AC_CHECK_LIB(uuid, uuid_generate, LIB_UUID="-luuid")],[
>> AC_MSG_RESULT(no)
>>
>>
>> *AC_MSG_CHECKING([for UUID support uuid and uuidgen] )*
>>
>>
>> * AC_TRY_COMPILE([#include <uuid.h>],[uuidgen;],[*
>>
>>
>> * AC_MSG_RESULT(yes) *
>>
>>
>> * AC_CHECK_LIB(uuid, uuidgen, LIB_UUID="-luuid" )],[*
>>
>> * AC_MSG_RESULT(no)*
>>
>>
>> *AC_PLUGIN_DISABLE*
>>
>> * ])*
>>
>> ])
>>
>> AC_SUBST(LIB_UUID)
>>
>>
>>
>>
>>
>> For the source code to see it, the config.h file needs to be in place
>> with that HAVE_UUID_H  flag*, so in Squeak, I over-ride the configH method
>> to include that define flag:
>>
>>
>> configH
>> ^ '
>>
>>
>> *#define HAVE_UUID_H 1 #define HAVE_UUIDGEN 1*
>>
>> #ifndef __sq_config_h
>>
>>
>> The CMakeVMMakerSqueak 'generate' message to a builder dumps that
>> config.h to the build directory.
>> running the build.sh generated script invokes
>>
>> cmake .
>>
>>
>>  command which looks in the specified source/config directory to
>> configure the GNU-Makefile to look for that source code and pairs it with
>> the generated config.h
>>
>> The CMake generate GNU-Make system then uses those source/build artifacts
>> to put the output in the oscogvm/products directory.
>>
>>
>> So, let me summarize.
>>
>> 1. We know that the plugins depend on config.h
>> 2. Ideally, that config.h should be incrementally build by the Squeak
>> plugins themselves or the CMakeVMMaker configurations. How? I don't know
>> yet. Looking at it, the UUIDPlugin class would have to contribute its
>> configuration information.
>>     this is non-trivial.
>> 3. So, in the meantime, CMakeVMMakerSqueak configurations are classes
>> that encapsulate a <drum roll please> Configuration.
>> 4. It seems reasonable to make this part of the configuration setup
>> process.
>> 5. I will/have documented in in the HelpBrowser HelpTopic for the system.
>>
>> My apologies for the long-winded explanation.
>>
>> HTH.
>>
>> tty
>>
>> *I just noticed the sys/uuid in the sqUnixUUID.c code, that implies a
>> further nesting in the .m4 file Let me know if you want me to write it for
>> you.
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140616/b962247c/attachment-0001.htm