[Vm-dev] updating configure.ac

Tobias Pape Das.Linux at gmx.de
Wed Oct 19 07:38:01 UTC 2016


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.

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.

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.

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.

Best regards
	-Tobias

PS: It would have been lots better to discuss such things over a whisky than over 8-bit ascii.
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


More information about the Vm-dev mailing list