[Vm-dev] updating configure.ac

phil at highoctane.be phil at highoctane.be
Tue Oct 18 22:14:51 UTC 2016


Does the simulator works in Pharo? Along with Display working?
Clement seems to be working with a Squeak based one.

TIA
Phil

On Wed, Oct 19, 2016 at 12:00 AM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Tobias,
>
> 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>
>> 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.
>>
>
> 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
>>         -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).
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161019/6b94f8d0/attachment.htm


More information about the Vm-dev mailing list