[Vm-dev] updating configure.ac
Eliot Miranda
eliot.miranda at gmail.com
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
More information about the Vm-dev
mailing list