<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Don't know if this is helpful but maybe...<div class=""><br class=""></div><div class=""><a href="https://stackoverflow.com/questions/2670121/using-cmake-with-gnu-make-how-can-i-see-the-exact-commands" class="">https://stackoverflow.com/questions/2670121/using-cmake-with-gnu-make-how-can-i-see-the-exact-commands</a><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 29, 2018, at 3:36 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class="">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:</div><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class="">-- Build files have been written to: /cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/release</div><div class="">make -C debug all</div><div class="">make[1]: Entering directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'</div><div class="">make[2]: Entering directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'</div><div class="">make[3]: Entering directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'</div><div class="">Scanning dependencies of target PharoVMCore</div><div class="">make[3]: Leaving directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/phar</div><div class="">o.cog.spur/debug'</div><div class="">make[3]: Entering directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'</div><div class="">[  1%] Building C object CMakeFiles/PharoVMCore.dir/platforms/Cross/vm/sqExternalSemaphores.c.o</div><div class="">In file included from /cygdrive/z/oscogvm/platforms/Cross/vm/sq.h:212:0,</div><div class="">                 from /cygdrive/z/oscogvm/platforms/Cross/vm/sqExternalSemaphores.c:31:</div><div class="">/cygdrive/z/oscogvm/platforms/minheadless/common/sqPlatformSpecific.h:36:39: fatal error: sqPlatformSpecific-Win32.h: No such file or directory</div><div class="">compilation terminated.</div><div class="">make[3]: *** [CMakeFiles/PharoVMCore.dir/build.make:63: CMakeFiles/PharoVMCore.dir/platforms/Cross/vm/sqExternalSemaphores.c.o] Error 1</div><div class="">make[3]: Leaving directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'</div><div class="">make[2]: *** [CMakeFiles/Makefile2:216: CMakeFiles/PharoVMCore.dir/all] Error 2</div><div class="">make[2]: Leaving directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'</div><div class="">make[1]: *** [Makefile:84: all] Error 2</div><div class="">make[1]: Leaving directory '/cygdrive/z/oscogvm/build.minheadless.cmake/x64/pharo.cog.spur/debug'</div><div class="">make: *** [Makefile:2: all] Error 2</div></div><div class=""><br class=""></div><div class="">What's missing? </div><div class="">- 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 platforms/minheadless/windows/sqPlatformSpecific-Win32.h</div><div class="">- 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</div><div class=""><br class=""></div><div class="">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 </div><div class="">- there is no slow configure step (the above make scheme crates 4 identical copies of a config file *on each build*)</div><div class="">- the commandos theat build are output explicitly so one may quickly debug errors in code one is writing</div><div class=""><br class=""></div><div class="">I'm sorry to complain but this use of cmake is painful and misguided.</div></div></div></div></div></div></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Nov 28, 2018 at 7:14 PM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" class="">eliot.miranda@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class="">Hi All,<div class=""><br class=""></div><div class="">    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*.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><div dir="ltr" class="m_9126227185341210645gmail_signature"><div dir="ltr" class=""><div class=""><span style="font-size:small;border-collapse:separate" class=""><div class="">_,,,^..^,,,_<br class=""></div><div class="">best, Eliot</div></span></div></div></div></div></div></div></div>
</blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class=""><span style="font-size:small;border-collapse:separate" class=""><div class="">_,,,^..^,,,_<br class=""></div><div class="">best, Eliot</div></span></div></div></div>
</div></blockquote></div><br class=""></div></body></html>