On Wed, Oct 19, 2016 at 3:38 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 19.10.2016, at 00:00, Eliot Miranda eliot.miranda@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