<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 16, 2014 at 4:38 PM, 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"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 16 June 2014 18:31, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></div></div></blockquote><div>My take on it goes from following:<br><br>you make two configuration - one which uses <br></div><div>/usr/include/uuid/uuid.h<br></div><div>another which uses<br></div><div>
/usr/include/uuid.h<br></div></div></div></div></blockquote><div><br></div><div>that way leads to generating the VM immediately before one builds, and that's a very bad direction because it goes against any repeatable build process that records the C source, that allows debugging older VMs etc. I disagree.</div>
<div><br></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 class="gmail_extra"><div class="gmail_quote"><div><br></div><div>and when you building VM you always know which one you build and which one works...<br>
</div><div>in contrast to situation when you have like 50+ automagically resolved flags & dependencies, so you don't even know what module is included into final artifact without checking it by hand.<br></div></div>
</div></div></blockquote><div><br></div><div>No, its not magic. Its autoconf/CMake. There's good reason to expect the maintainers of autoconf and CMake to do a better job detecting and deciding on the right platform make files for a given unix than the Pharo/Squeak community. i.e. thousands of unix programs, many of them critical infrastructure such as apache were built using autoconf and are buult using CMake. Your approach complicates the lives of people trying to port to unusual unix platforms such as Open Solaris, FreeBSD etc. I don't see the point of forcing people through the VM generation step just to manually do a configuration their platform tools will do for them.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Because when i want to build VM which includes/uses feature X, it should include X, not X' or Y, (or even worse - automatically ignore it because it's not avail on your system).<br>
</div><div>Because if feature cannot be strictly guaranteed, i prefer to see the build process to simply abort reporting failure.. instead of behave fuzzily & be smart and nicely trying to guess best possible combination of bells & whistles to build on current platform.. it is wrong place for being smart.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></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></div></div></div></blockquote><div>does it really matters at which point you decide how to configure build?<br></div></div></div></div></blockquote><div><br></div><div>Yes.</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 class="gmail_extra"><div class="gmail_quote"><div></div><div>what matters that you will always would want to configure it.. and you always would want to spend as little as possible time on it.. and having things easy and convenient to configure or modify. <br>
</div><div>And what can be better place to configure things than smalltalk environment? :)<br></div></div></div></div></blockquote><div><br></div><div>Seriously? You think Sueak/Pharo is better connected to unix platform libraries than autoconf/CMake? We can't even do symlinks properly yet.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Perusing classes & methods, or perusing files in numerous (sub)directories + requiring knowledge of makefile & autoconf DSLs.. which are worst nightmare? For me the choice was obvious.. <br>
yes, you still cannot avoid some perusing.<br></div><div>that is inevitable part of process, but at least you can choose where (not) to do it. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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-color:rgb(204,204,204);border-width:1px;border-style:solid;padding: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-color:rgb(204,204,204);border-width:1px;border-style:solid;padding: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-color:rgb(204,204,204);border-width:1px;border-style:solid;padding: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-color:rgb(204,204,204);border-width:1px;border-style:solid;padding: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-color:rgb(204,204,204);border-width:1px;border-style:solid;padding: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>
<br></blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br>Igor Stasenko.
</div></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>