[Vm-dev] The insanity of using make for development builds

Eliot Miranda eliot.miranda at gmail.com
Thu Nov 29 23:36:20 UTC 2018

and then  there's this.  Having spotted the apparent error (a case
difference for sqPlatformSpecific-Win32.h in
platforms/minheadless/common/sqPlatformSpecific.h) I rerun the build and
see the following output, essentially unchanged:

-- Build files have been written to:
make -C debug all
make[1]: Entering directory
make[2]: Entering directory
make[3]: Entering directory
Scanning dependencies of target PharoVMCore
make[3]: Leaving directory
make[3]: Entering directory
[  1%] Building C object
In file included from /cygdrive/z/oscogvm/platforms/Cross/vm/sq.h:212:0,
fatal error: sqPlatformSpecific-Win32.h: No such file or directory
compilation terminated.
make[3]: *** [CMakeFiles/PharoVMCore.dir/build.make:63:
Error 1
make[3]: Leaving directory
make[2]: *** [CMakeFiles/Makefile2:216: CMakeFiles/PharoVMCore.dir/all]
Error 2
make[2]: Leaving directory
make[1]: *** [Makefile:84: all] Error 2
make[1]: Leaving directory
make: *** [Makefile:2: all] Error 2

What's missing?
- no mention of a LOG file name to go look for the command line for the
compiler which is likely missing an include path to pick up
- no command line so one can't merely eyeball the output to  heck, or run
the build with output piped into one's own LOG file

What doe we see?  An opaque build system.  The only way to approach this is
to wade through the details trying to uncover things *that should be in
plain view*.  With the Makefiles I have written
- there is no slow configure step (the above make scheme crates 4 identical
copies of a config file *on each build*)
- the commandos theat build are output explicitly so one may quickly debug
errors in code one is writing

I'm sorry to complain but this use of cmake is painful and misguided.

On Wed, Nov 28, 2018 at 7:14 PM Eliot Miranda <eliot.miranda at gmail.com>

> Hi All,
>     I've just attempted to build minheadless on win32 in
> build.minheadless.cmake.  It failed, but it took a long time to do so,
> while I waited.  So I cleaned and repeated to measure just how long I
> waited.  So this time is a best case; all read files are in cache etc.  I'm
> running a Windows VM on a top of the line MacBook Pro and yet it takes 3
> minutes and 20 seconds to configure and then start to build and fail
> because it can't find sqplatfozrmspecifc-win32.h.  I have to wait 3 minutes
> and 20 seconds before I can find out a missing file.  This is *wrong*.
> Using make on a build slave is fine, if you insist, but clearly not
> necessary (our current builds do not use cmake, and even then on ARM build
> slaves they sometimes timeout).  But for development this is madness.  We
> should have a build system which is reactive, which gives feedback too the
> developer quickly, not after 3 minutes and 20 seconds on state of the art
> hardware.
> I find it absurd that a Smalltalk community, which well understands the
> value of incrementally and reactivity, can be satisfied with a VM build
> system that takes 3 minutes and 20 seconds before it does anything useful.
> It feels like being back at York University in the early '80's, waiting for
> the PDP 10.  No, that was faster.  On reflection, it reminds me of having
> to post coding sheets to be typed in by entry clerks through the mail while
> I was at school in the '70's.  Back to the future indeed.
> _,,,^..^,,,_
> best, Eliot

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181129/5f5bd695/attachment-0001.html>

More information about the Vm-dev mailing list