[Vm-dev] updating configure.ac

Esteban Lorenzano estebanlm at gmail.com
Tue Oct 18 06:41:31 UTC 2016


> On 18 Oct 2016, at 07:49, Tobias Pape <Das.Linux at gmx.de> wrote:
> 
> 
> 
> On 18.10.2016, at 02:57, Ben Coman <btc at openinworld.com> wrote:
> 
>> 
>> 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...
>>>>> 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 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.
> 
> ACK.
> it can generate Xcode, VisualStudio, Eclipse… project files, which _tremendously_ eases
> debugging.
> 
> Dear CogVM builders, what is the IDE you use for development and debugging that works
> with the "only for config.h" scheme? I'm really interested.
> (And no, editor+gdb does not count)

XCode for macOS 
	you need to create a “fake” xcode project pointing to sources (but you do not need to “add” sources), it works… fine (I didn’t spend much time optimising it, anyway)

Eclipse CDT standalone debugger for linux/win
	this is fairly straightforward. 

in both cases my approach is as follow: 

- launch debugger/IDE
- build debug/assert vm from command line
- attach to running process 

but that doesn’t mean I’m contrary to your approach, just that there are ways to use a decent debugger anyway :)

Esteban

> 
> Best regards
> 	-Tobias
> 
> 
>> If we are not
>> doing that, there seems little imperative to move from autoconf to
>> cmake.  Autoconf reportedly has slightly better coverage of feature
>> determination.
>> 
>> btw, I found this an interesting insight...
>> http://stackoverflow.com/questions/4071880/autotools-vs-cmake-vs-scons
>> 
>> "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).
> 



More information about the Vm-dev mailing list