Eliot Miranda wrote:





On Fri, Jun 27, 2014 at 1:46 PM, gettimothy <gettimothy@zoho.com> wrote:
 
Hi all

In Ian's CMake infrastructure, the instructions require the user to run the configure command before invoking cmake.

For the CMakeVMMaker(Squeak) we currently have config.h embedded in the class. 

For my first configuration after this massive refactoring I have done, I first ran the 'mvm' on the GNU side and then cut-n-paste that generated config.h into my class.

Tta;s an absurd thing to do.  It means that we need a different class for every single different release of a Unix OS, because the generated config.h could potentially change with every different release of a Unix OS.  config.h has *no* place in the image.  It must be generated at compile time.

Following a post by Igor in a different thread [1], I also wondered whether running configure and storing the results in image would be useful.  I haven't done much system programming, so excuse my naivety, but doesn't `configure` only make sense for the system you are compiling on?  What if you want to cross-compile form one Linux distribution-release to an older release, or another distribution, which might be at a client site.  At first glance it seems having cached "configure" result wold be useful, otherwise you'd need to install the client's distribution-release to do it? (and maybe that would be a good idea anyway, but should it be a constraint?).

I wonder if there is some middle ground, where `configure` results could be stored as different methods on one particular class - similar to how Metacello does its versioning.  These could be added by different groups working with the VM as extension methods from their own packages.  The default would be generate config.h at compile time, but you'd be able to substitute with a call to one of these cached `configure` methods.

I half-expect this won't be well received :), but its my current thinking, so I'll be learning something in any case.
cheers -ben

[1] Subject: tty's hypothesis on configH in CMakeVMMaker"

 

That's ok for an intermediate step, but I would like to take it a step further and...

1. invoke configure from squeak (I have the configure flags like '--without-npsqueak --without-gl...etc" embedded in the class, so they are avaiable to invoke configure with)
2. detect the success or failure of the configure command 
3. if successful, load the generated config.h into my class (actually, this is redundant, but it may come in handy)
4. continue as normal.

Does this sound reasonable to everybody?


thx,


tty






--
best,
Eliot