[Vm-dev] updating configure.ac
btc at openinworld.com
Tue Oct 18 00:57:42 UTC 2016
On Tue, Oct 18, 2016 at 5:31 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Phil,
> On Mon, Oct 17, 2016 at 12:31 AM, phil at highoctane.be <phil at highoctane.be> wrote:
>> On Mon, Oct 17, 2016 at 8:59 AM, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>>> 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 this...
>>> 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 tools.
> 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
> - 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).
More information about the Vm-dev