[Vm-dev] updating configure.ac
Gerardo Santana Gómez Garrido
gerardo.santana at gmail.com
Tue Oct 18 03:27:17 UTC 2016
Autoconf crash course
Software developer task
create feature tests (configure.ac) and generate portable shell script
(configure) for executing these tests on each platform. Include this script
in distribution file for end users that wish to build the software
configure.ac ---> [autoconf] ---> configure
Optionally, the software developer can include the feature tests (
configure.ac) so that another software developer can add more feature tests
for adding support for other platforms.
End user task
run portable shell script and build.
./configure && make && make install
the configure script is parameterized in a way that enables end users to
satisfy its tests (e.g. location of libraries or header files). It can
process templates files (e.g. Makefile.in) and generates config.h.
Today, the configure.ac checked into the repository is *not* the one that
generated the configure script. That means that we can't use that
configure.ac to generate a new configure script, which in turn means that
another developer can't add new feature tests to configure.ac (e.g. for
adding support for other platforms.)
For instance, I can't add tests for safer string manipulation functions to
compile external ones if needed.
We could have a single source tree for all UNIX-like and GNU/Linux
distributions if only we could fix that.
P.S. The current configure script was generated with autoconf 2.59. You
will need to use the same autoconf 2.59 to process configure.ac to try to
get the same configure script.
On Mon, Oct 17, 2016 at 7:57 PM, Ben Coman <btc at openinworld.com> wrote:
> On Tue, Oct 18, 2016 at 5:31 AM, Eliot Miranda <eliot.miranda at gmail.com>
> > Hi Phil,
> > On Mon, Oct 17, 2016 at 12:31 AM, phil at highoctane.be <phil at highoctane.be>
> >> On Mon, Oct 17, 2016 at 8:59 AM, Esteban Lorenzano <estebanlm at gmail.com>
> >>> On 17 Oct 2016, at 02:07, Ben Coman <btc at openInWorld.com> wrote:
> >>> Phil, Could you outline the steps. Are you doing something other than
> >>> https://github.com/pharo-project/pharo-vm
> >>> I think he is talking “in general”, not about the VM in particular.
> >> In general. But also about the VM since I wanted to build it for
> OSX/Win/Linux and CMake + the image code supporting it, while initially a
> royal PITA (version had to be correct etc) proved to be very useful for a
> lot of things because it was all logical, variables could be set nicely etc.
> >> The CMake UI also allows to detect for a number of crappy mistakes, so,
> a godsend.
> >> It can also generate XCode project files, which is very useful.
> >> autoconf and makefiles, no thanks.
> >> The image side CMake support looks great to me, better than the VMMaker
> green UI, which well, let's keep it at that.
> > That tool is not used to generate VM source.
> >> It also working nice with a CI server, so why use stoneage tooling when
> you have a more modern one available?
> >> Learn the damn CMake and profit. We want a great VM, let's use great
> > There is agreement amongst the CogVM builders that
> > - we will use cake or autoconf to generate a cogConfig.h that describes
> the build target platform's capabilities
> > - we will /not/ use either autoconf or cake to generate VM makefiles
> Most of my reading indicates the main virtue of CMake over autoconf is
> the generation of makefiles for different build systems. If we are not
> doing that, there seems little imperative to move from autoconf to
> cmake. Autoconf reportedly has slightly better coverage of feature
> btw, I found this an interesting insight...
> "An important distinction must be made between who uses the tools.
> Cmake is a tool that must be used by the user when building the
> software. The autotools are used to generate a distribution tarball
> that can be used to build the software using only the standard tools
> available on any SuS compliant system. In other words, if you are
> installing software from a tarball that was built using the autotools,
> you are not using the autotools. On the other hand, if you are
> installing software that uses Cmake, then you are using Cmake and must
> have it installed to build the software.
> The great majority of users do not need to have the autotools
> installed on their box. Historically, much confusion has been caused
> because many developers distribute malformed tarballs that force the
> user to run autoconf to regenerate the configure script, and this is a
> packaging error. More confusion has been caused by the fact that most
> major linux distributions install multiple versions of the autotools,
> when they should not be installing any of them by default. Even more
> confusion is caused by developers attempting to use a version control
> system (eg cvs, git, svn) to distribute their software rather than
> building tarballs."
> cheers -ben
> > - we will write linux makefiles in the style of the windows and mac
> makefiles, all using gmake
> > We are not using bad tools; cake and autoconf are all useful in their
> place, but experience has shown that they are not good tools for generating
> the makefiles we use to build the VM, primarily because they are slow,
> being painful to run on each make, and because they are higher-order, so
> figuring out what input to change to achieve a changed output is indirect,
> and may require a build step (running autoconf/cmake). The makefiles we
> have for windows and mac are much better; they are fast, running
> immediately, and direct, their configuration options never depend on
> rebuilding the make system, only in their configuration files (plugins.int,plugins.ext
> and attendant platforms/foo/plugins/Makefile files).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev