[Vm-dev] updating configure.ac
eliot.miranda at gmail.com
Tue Oct 18 22:00:27 UTC 2016
On Mon, Oct 17, 2016 at 10:49 PM, 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>
> >> 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
> >> 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.
> it can generate Xcode, VisualStudio, Eclipse… project files, which
> _tremendously_ eases
With respect, only in limited genres. Firstly VM debugging is much easier
in the simulator than in C. No ammount of navigation through the C code
can compensate for the fact that the C is an output language, and not the
language of implementation for the key parts of the VM. Second, in
debugging the core VM, the support functions that print stack frames and
backtraces, objects, references to objects, free lists, etc, etc. It is
these that make i possible to debug the VM (as an execution engine, not the
support C code), and make project files an inadequate solution. VM state
is /not/ the C stack, the locus of attention in a traditional C debugger.
> 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)
The simulator, primarily, i.e. Squeak or Pharo. Next, indeed gdb or lldb
plus the significant number of debugging functions included in the VM. And
it /does/ count.
That said, I have no objection if someone builds a CMake scheme to generate
project files for those debugging support C code. I will still council
that this effort is wasted when trying to debug the VM as an execution
engine; for that one really has to learn the architecture and become
familiar with the debug functions (and yes, good documentation would help
here, and a lot more than a project file).
What I *do* object to is the use of these project files for a build
system. For the last time, I *will not* support such a move. Experience
has shown (already 8 yard on Cog) that these get in the way of an efficient
build system; they are inflexible and slow. The lean mean gmake files are
much much better. So _please_ desist from pushing project build makefiles
via CMake. I find this direction antagonising; I have expressed myself
clearly on the point, and I have not seen any convincing counterarguments.
So can we please settle on the fact that we have agreed to use gmake
makefiles for builds. Enough said?
> Best regards
> > 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev