[Vm-dev] updating configure.ac

Ben Coman btc at openinworld.com
Wed Oct 19 13:00:51 UTC 2016


On Wed, Oct 19, 2016 at 3:38 PM, 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.
>
> 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.
>

> [1] opensmalltalk-vm$ find . -name mvm |wc -l
>      114

Most of those come from the repetition of the debug folders under the
linux builds, which will improve when they become more like mac
builds.

build.linux32ARMv6
18
build.linux32ARMv7
6
build.linux32x86
51
build.linux64x64
21

build.win32x86
6
build.win64x64
4

build.macos32x86
10
build.macos64x64
7


> [2] opensmalltalk-vm$ find . -name makefile |wc -l
>      356

Strange I only get
find . -iname makefile | wc -l

> [3] opensmalltalk-vm$ find . -iname make\* | wc -l
>      477
>     (- 88 makefiles)

What I get from...
  for d in * ; do
      echo $d
      find $d -iname makefile | wc -l
  done

build.linux32ARMv6
0
build.linux32ARMv7
0
build.linux32x86
1
build.linux64x64
0
build.macos32x86
20
build.macos64x64
17
build.win32x86
9
build.win64x64
6
platforms
48
processors
12

Now most of the mac makefiles are three lines long
e.g. build.macos32x86/squeak.cog.spur/Makefile

And to drilling into platforms...
Cross
3
iOS
29
Mac OS
0
Plan9
0
RiscOS
1
unix
6
win32
9

and processors...
ARM
6
IA32
6


Now performing an actual build I get this maybe makefiles
mybuild
53

so it seems the autogeneration of makefiles seems the big culprit, and
I'd expect CMake may be similar here.


> [4] opensmalltalk-vm$ ls -d1 build.{mac,win}*/*.*.*/  | wc -l
>     28
>     opensmalltalk-vm$ ls -d1 build.linux*/*.*.*/build*  | wc -l
>     87

The linux build system is planned to become more like win & mac,
so consider that 87 coming down to around 14 ??

(gotta run)

cheers -ben


More information about the Vm-dev mailing list