[Vm-dev] updating configure.ac

Wed Oct 19 18:56:36 UTC 2016

Tobias,

On Wed, Oct 19, 2016 at 12:38 AM, Tobias Pape <Das.Linux at gmx.de> wrote:

>
>
> On 19.10.2016, at 00:00, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> > 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.
>
> I still disagree.
>
> I agree that for you as VM/Interpreter/Cog developer, your workflow is
> useful, lean, and debugging apparently ok.
>
> But seeing that the second PR from the first external contributor is
> _changing the build system_ speaks volumes.
> Also, all students I have seen that wanted to play around with the VM were
> startled by the build process and needed individual help to get going.
>

They are changing the linux autoconf build system.  It's broken.  I really
don't want

> But more so, except for the people working on the actual execution engine
> (Which is probably only you, David, maybe Bert and Tim and Tim),
> all other contributors typically do not touch or care for the VMMaker part
> or even the simulator.
>

Nicolas Cellier (arithmetic)

>
> It is about the hand-written C (or ObjC) stuff. gdb does not help when
> SecureTransport does strange things, gdb does not help if I have to debug
> the ANSI->Wide->UTF8 ordeal on windows.
>
> It took me one and a half days to collect all information necessary to
> make a VisualStudio project that I could use to test Cog on VisualC. Just
> to discover that somewhere a C file includes a complete other C-file.
> Collecting all the defines took hours.
>

So use CMake to generate it.  I don't disagree.  But /do not/ force me to
use CMake to build the VM.  I have explained, and I want you to accept, hat
the gmake makefile scheme is a very good one.

>
> I have yet to collect all the files necessary to have a proper Xcode
> project that helps me debugging.
>
> I do not speak of debugging the  interpreter or debugging the JIT. Just
> the platform relevant files, or the plugins.
>
> We have 114 'mvm' scripts[1], 356 makefiles[2], 121 maker-script[3], and
> whooping 115 VM-configuration expressed as _directories_[4].
>
> Ain't nobody got time to read this.
>
> There's frequent complaining that too few people help with VM development.
> I understand and second.
>
> But this is no ecosystem that encourages helping.
>
> >  Enough said?
>
> You're not gonna change a thing that hurts you, thats ok.
> But please do not expect people who want to help to do it solely on your
> terms.
>

I'm NOT saying you cannot generate project makefiles.  For the LAST TIME, I
am saying I will not accept the VM being *built* with a project file.

I'm fed up of repeating myself.

>
> Best regards
>         -Tobias
>
> PS: It would have been lots better to discuss such things over a whisky
> than over 8-bit ascii.
>

+1.

> PPS: HTML mail garbles the reply-quotation.
>
>
> [1] opensmalltalk-vm$ find . -name mvm |wc -l
>      114
> [2] opensmalltalk-vm$ find . -name makefile |wc -l
>      356
> [3] opensmalltalk-vm$ find . -iname make\* | wc -l
>      477
>     (- 88 makefiles)
> [4] opensmalltalk-vm$ ls -d1 build.{mac,win}*/*.*.*/  | wc -l
>     28
>     opensmalltalk-vm$ ls -d1 build.linux*/*.*.*/build*  | wc -l
>     87

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161019/97d0d0c3/attachment.htm