<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 16, 2014 at 3:33 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr"><div><div>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.<br>
</div>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. <br>
</div><div>They must be defined once and stay same regardless of building environment.<br></div><br><div>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.<br>
</div><div>And sure thing, for having variations, you can define own configuration e.g. MyVMWith(orWithout)UUID<br></div><div>and use it to compile VM with that flag changed.<br></div><div>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.<br>
</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>
</div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 15 June 2014 23:27, gettimothy <span dir="ltr"><<a href="mailto:gettimothy@zoho.com" target="_blank">gettimothy@zoho.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><u></u><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif"><div>Hi Eliot.<br></div><div>
<br></div><div><br></div><div><br></div><div>I have a theory on the Pharo CMakeVMaker configH method. </div><div><br></div><div><br><blockquote style="border-top-color:rgb(204,204,204);border-left-color:rgb(204,204,204);border-right-color:rgb(204,204,204);border-bottom-color:rgb(204,204,204);border-top-width:1px;border-left-width:1px;border-right-width:1px;border-bottom-width:1px;border-top-style:solid;border-left-style:solid;border-right-style:solid;border-bottom-style:solid;padding-top:7px;padding-right:7px;padding-bottom:7px;padding-left:7px;background-color:rgb(245,245,245)">
<div>CogUnixConfig configH<br>        " right now its like that "<br>        ^ '<br>#ifndef __sq_config_h<br>#define __sq_config_h<br><br>/* explicit image width */<br><br>#define        HAVE_INTERP_H 1<br></div><div><br></div>
<div>....</div><div><br></div></blockquote> </div><div><br></div><div>based on my work getting the oscogvm/platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c... to compile.</div><div>Working from the C source up to configuration then to Squeak....we start with the source code for sqUnixUUID.c</div>
<br><blockquote style="border-top-color:rgb(204,204,204);border-left-color:rgb(204,204,204);border-right-color:rgb(204,204,204);border-bottom-color:rgb(204,204,204);border-top-width:1px;border-left-width:1px;border-right-width:1px;border-bottom-width:1px;border-top-style:solid;border-left-style:solid;border-right-style:solid;border-bottom-style:solid;padding-top:7px;padding-right:7px;padding-bottom:7px;padding-left:7px;background-color:rgb(245,245,245)">
<div><div>#include "config.h"<br><br>#if defined(HAVE_SYS_UUID_H)<br># include <sys/types.h><br># include <sys/uuid.h><br>#elif defined(HAVE_UUID_UUID_H)<br># include <uuid/uuid.h><br>#elif defined(HAVE_UUID_H)<br>
# include <uuid.h><br>#else<br># error cannot find a uuid.h to include<br>#endif<br></div></div></blockquote> <br><div>On my platform, I needed that HAVE_UUID_H define set. </div><div>To do that, I modified the acinclude.m4 file to check for the <uuid.h> (my changes in Bold--I emailed you this previously)</div>
<div><br></div><div><br><blockquote style="border-top-color:rgb(204,204,204);border-left-color:rgb(204,204,204);border-right-color:rgb(204,204,204);border-bottom-color:rgb(204,204,204);border-top-width:1px;border-left-width:1px;border-right-width:1px;border-bottom-width:1px;border-top-style:solid;border-left-style:solid;border-right-style:solid;border-bottom-style:solid;padding-top:7px;padding-right:7px;padding-bottom:7px;padding-left:7px;background-color:rgb(245,245,245)">
<div>AC_MSG_CHECKING([for UUID support uuid/uuid.h] and uuid_generate)<br>AC_TRY_COMPILE([#include <uuid/uuid.h>],[uuid_generate;],[<br> AC_MSG_RESULT(yes)<br> AC_CHECK_LIB(uuid, uuid_generate, LIB_UUID="-luuid")],[<br>
AC_MSG_RESULT(no)<br><blockquote> <b>AC_MSG_CHECKING([for UUID support uuid and uuidgen] )<br></b></blockquote><blockquote><b> AC_TRY_COMPILE([#include <uuid.h>],[uuidgen;],[<br></b></blockquote><blockquote><b> AC_MSG_RESULT(yes)<br>
</b></blockquote><blockquote><b> AC_CHECK_LIB(uuid, uuidgen, LIB_UUID="-luuid" )],[<br></b></blockquote><blockquote><b> AC_MSG_RESULT(no)</b><br></blockquote><blockquote> <b>AC_PLUGIN_DISABLE<br></b></blockquote>
<blockquote><b> ])</b><br></blockquote>])<br><br>AC_SUBST(LIB_UUID)<br><br> </div></blockquote><br><br>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:<br>
</div><div><br></div><div><br><blockquote style="border-top-color:rgb(204,204,204);border-left-color:rgb(204,204,204);border-right-color:rgb(204,204,204);border-bottom-color:rgb(204,204,204);border-top-width:1px;border-left-width:1px;border-right-width:1px;border-bottom-width:1px;border-top-style:solid;border-left-style:solid;border-right-style:solid;border-bottom-style:solid;padding-top:7px;padding-right:7px;padding-bottom:7px;padding-left:7px;background-color:rgb(245,245,245)">
<div>configH<br>        ^ '<br><br><b>#define HAVE_UUID_H 1 <br>#define HAVE_UUIDGEN 1</b><br><br>#ifndef __sq_config_h</div></blockquote> <br></div><div>The CMakeVMMakerSqueak 'generate' message to a builder dumps that config.h to the build directory.</div>
<div>running the build.sh generated script invokes<br><blockquote style="border-top-color:rgb(204,204,204);border-left-color:rgb(204,204,204);border-right-color:rgb(204,204,204);border-bottom-color:rgb(204,204,204);border-top-width:1px;border-left-width:1px;border-right-width:1px;border-bottom-width:1px;border-top-style:solid;border-left-style:solid;border-right-style:solid;border-bottom-style:solid;padding-top:7px;padding-right:7px;padding-bottom:7px;padding-left:7px;background-color:rgb(245,245,245)">
<div>cmake .</div></blockquote> <br> 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</div><div><br></div><div>
The CMake generate GNU-Make system then uses those source/build artifacts to put the output in the oscogvm/products directory.</div><div><br></div><div><br></div><div>So, let me summarize.</div><div><br></div><div>1. We know that the plugins depend on config.h</div>
<div>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.</div>
<div> this is non-trivial.</div><div>3. So, in the meantime, CMakeVMMakerSqueak configurations are classes that encapsulate a <drum roll please> Configuration.</div><div>4. It seems reasonable to make this part of the configuration setup process.</div>
<div>5. I will/have documented in in the HelpBrowser HelpTopic for the system.</div><div><br></div><div>My apologies for the long-winded explanation. </div><div><br></div><div>HTH.</div><div><br></div><div>tty</div><div>
<br>
</div><div>*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.</div></div></div><br></blockquote></div><br><br clear="all">
<br>-- <br>Best regards,<br>Igor Stasenko.
</div><br></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>