[Vm-dev] running 'configure' command from within Squeak and then loading that config.h into my object...similar work done?

David T. Lewis lewis at mail.msen.com
Sat Jun 28 00:28:59 UTC 2014

On Fri, Jun 27, 2014 at 04:58:12PM -0700, Eliot Miranda wrote:
> On Fri, Jun 27, 2014 at 2:19 PM, gettimothy <gettimothy at 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)..

Indeed, there were a number of problems with autotools, and IIRC the related
problems with libtool handling of mixed 32-bit and 64-bit libraries created
such a mess that it finally drove Ian to create the CMake build, which has
been relatively problem free ever since.

Regarding autotools, see note #4 below. Note #5 is also worthy of some
thoughtful consideration.


$ ./platforms/unix/cmake/configure --help
Usage: ./configure [options...]
Options include:
  --help                print this message and then exit
  --src=<directory>     look for generated interpreter sources in <directory>
  --prefix=<directory>  install into <prefix>/{bin,lib,man}
  --CFLAGS=<flags>      override default compiler flags
  --without-<plugin>    do not build the named plugin
  --without-gl          disable everything that depends on OpenGL
  --without-SUGAR       disable support for SUGAR environment
  --image64             build a VM for running 64-bit images
  --enableFastBlt       use optimised BitBlt (not supported on most platforms)
1. By default the CFLAGS will be set to create optimised binaries.  If you are
   debugging the VM you probably want to use '--CFLAGS=-g' when invoking this
2. --CFLAGS and -without-* settings will be preserved in subsequent invocations
   of CMake, including those driven implicitly by changed dependencies.  If you
   need to turn off a seting (to re-enable a plugin or restore the default
   CFLAGS) just give the relevant options with empty arguments, like this:
     ./configure --CFLAGS= --without-UUIDPlugin=
3. Wizards can set any CMake variable from the command line with the option:
4. In case it isn't already obvious, this is NOT the autotools 'configure'
   script.  It is named so that 'configure; make' works in the expected way.
5. Bug reports, bug fixes and suggestions for improvement should be sent to the
   author (Ian Piumarta) at: <firstName> (at) <lastName> (dot) com

More information about the Vm-dev mailing list