On Fri, Jun 27, 2014 at 2:19 PM, gettimothy gettimothy@zoho.com wrote:

HI Eliot and Tim.

Makes sense to me. What I am trying to figure out is the best way to generate it at compile time and ditch the hard-coded configH method per the requirements.

One option is to just invoke configure per the build.linuxXYZ/build/mvm file as the source tree is identical.

Would that be a problem?

Well, if you're doing CMake then you'll want to use whatever CMake uses to generate config.h. platforms/unix/conf/configure runs automake.

Another possibility is in Ian's CMake system for the Standard Interpreter,

it is generated by hand.

Even if configure was generated by automake its input files (configure.in et al) were not ;-)

One could see that inputs to CMake are hand-written as an advantage of CMake, it getting one further in each step. autoconf's generating configure is problematic, configure itself needing to be generated on the right system (generating it on Mac OS X for example produces a completely broken configure)..

svn co http://squeakvm.org/squeak/trunk squeak cd squeak mkdir bld cd bld *../platforms/unix/cmake/configure* make

Looking at that /platforms/unix/cmake/configure file, it is just a shell script with some hard-coded definitions/flags.

What I could do is dynamically create that ../platforms/unix/cmake/configure script from the class. Then in the build script build.sh invoke that script first before invoking cmake.

I do think the first option is easier.

Thoughts?

thx.

tty

Hi David,

See my last reply to Eliot.

I have been neck deep in new coding that I have relied on the existing CMakeVMaker approach to drive my development.

While replying to Eliot and Tim R, I have glanced at Ian's configure script and I think this will all come together nicely.

The end of Ian's script invokes cmake like so:

if test -n "${cflags}"; then cmake "${unix}" -DVM_HOST="${host}" -DVM_VERSION="${VM_VERSION}" -DPLATFORM_SOURCE_VERSION="${PLATFORM_SOURCE_VERSION}" -DSRC="${src}" -DOPT--CMAKE_C_FLAGS="${cflags}" ${args} else cmake "${unix}" -DVM_HOST="${host}" -DVM_VERSION="${VM_VERSION}" -DPLATFORM_SOURCE_VERSION="${PLATFORM_SOURCE_VERSION}" -DSRC="${src}" ${args} fi

Which, somehow creates a config.h (and a good looking one too. It links to /lib/64 which is correct on my system)

This is definitely solvable in principle using exclusivelly cmake.

I have a lot of brain-cycles to spend getting the framework in place before I turn my attention to this particular problem, but in discussing it with you guys, the solution has presented itself.

cheers.

tty

Hi Eliot

Thanks for the reply.

>>Well, if you're doing CMake then you'll want to use whatever CMake uses to generate config.h. platforms/unix/conf/configure runs automake.

Yeah, its on my list. I don't know what (or if) cmake uses to generate config.h. Ian's configure script looks like a hand-coded bash script that does in bash what we are doing in Squeak, the penultimate line in that script reads like this:

cmake "${unix}" -DVM_HOST="${host}" -DVM_VERSION="${VM_VERSION}" -DPLATFORM_SOURCE_VERSION="${PLATFORM_SOURCE_VERSION}" -DSRC="${src}" -DOPT--CMAKE_C_FLAGS="${cflags}" ${args}

I will get to that, but I have bigger fish to fry beforehand. I do believe the problem is solvable in a clean way.

An interim solution hit me on my way to friends house for dinner a while ago.

The VMMakerCMake(Squeak) system generates a 'build.sh' script that reads..

#!/usr/bin/env bash

if [ ! -e vmVersionInfo.h ]; then ../scripts/extract-commit-info.sh fi cmake . make

What I can do in the interim is utilize the configure line from the mvm files and do ....

#!/usr/bin/env bash

if [ ! -e vmVersionInfo.h ]; then ../scripts/extract-commit-info.sh fi ../../platforms/unix/config/configure --with the flags I store in the configuration class for this configuration/buildType cmake . make

That is the autoconfig stuff for now.

I will give that a go in the a.m. Then/if the cmake system has the config.h generation capabilities, I will roll that into the system.

Then, when I have the system in place, I can study what Ian is doing and modify the script to something like

#!/usr/bin/env bash

if [ ! -e vmVersionInfo.h ]; then ../scripts/extract-commit-info.sh fi cmake "${unix}" -DVM_HOST="${host}" -DVM_VERSION="${VM_VERSION}" -DPLATFORM_SOURCE_VERSION="${PLATFORM_SOURCE_VERSION}" -DSRC="${src}" -DOPT--CMAKE_C_FLAGS="${cflags}" ${args} make

cheers.

tty.

P.S. That

cmake "${unix}" -DVM_HOST="${host}" -DVM_VERSION="${VM_VERSION}" -DPLATFORM_SOURCE_VERSION="${PLATFORM_SOURCE_VERSION}" -DSRC="${src}" -DOPT--CMAKE_C_FLAGS="${cflags}" ${args}

command does in fact generate a config.h, so the problem is solvable in principle. I just have a lot of boilerplate heavy lifting to do prior to turning my attention to that line and learning how it interacts with the existing CMakeLists.text.

Thanks for your patience. Sometimes it helps to just talk out loud about a problem.

cheers again.

tty

Hi Ben,

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

I discovered yesterday during the email exchange on this subject that Ian's configure script and CMakeLists.txt work together to create a config.h without using the auto-tools; this is the approach I will be taking. I will be turning my attention to it in a couple of days.

cheers.

tty.