<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi All,</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"> and from a related thread:</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">On Apr 2, 2018, at 12:31 PM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:</span></font><div><span style="background-color: rgba(255, 255, 255, 0);">[snip]</span></div></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">Note that the ARM builds are very slow (not finished after 16 minutes), I think that it was the reason to put them at end of Queue.<br></span></font></div></div></div></div></blockquote><div id="AppleMailSignature"><br></div>the use of just makefiles avoids the configure run and so builds are /much/ faster</div><div id="AppleMailSignature"><br><span style="background-color: rgba(255, 255, 255, 0);">_,,,^..^,,,_ (phone)</span></div><div><br>On Apr 2, 2018, at 3:54 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Hi Holger,</span><br><span></span><br><blockquote type="cite"><span>On Apr 2, 2018, at 7:00 AM, Holger Freyther <<a href="mailto:holger@freyther.de">holger@freyther.de</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On 2. Apr 2018, at 14:51, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Gah!</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>despite my stuttutututter command:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> CC=clang ./configure CC=clang</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>the travis build is completely ignoring the directives and keep using gcc</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>See:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/361174043">https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/361174043</a> <<a href="https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/361174043">https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/361174043</a>></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I suspect that it's lack of clean build, but not sure...</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Building OpenSmalltalk VM in /home/travis/build/OpenSmalltalk/opensmalltalk-vm/build.linux32x86/pharo.sista.spur/build.itimerheartbeat...</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><>Re-exec as x86</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><>clean? ok but this isn't safe!!</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Or would the clang compiler be absent?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Or what?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>It ain't fun...</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The cost of abstraction... I am not a fan of the "build" scripts (a lot of code cloning for what[1] gain?) and the travis logs don't show us the invocation of the actual commands.</span><br></blockquote><span></span><br><span>The complexity is due to the arcane nature of the Linux/Unix build system and its use of autoconf and several scripts to generate makefiles. I have been saying for years that we need to rewrite the Linux build system to use convention makefiles as per Andreas' Windows makefiles and my subsequent Mac OS Makefiles. I rewrote the Mac OS build system to use makefiles (*) and you'll notice that</span><br><span>- all share a small suite of makefiles in build.macosXXX/common</span><br><span>- all have a single top-level Makefile that defines the vm variant (the vm source directory) and some branding</span><br><span>- all mvm scripts under build.macosXXX are identical and serve only to invoke make with the three variants, production, assert & debug VMs</span><br><span>Indeed were it not for no symbolic link support for git/svn et al on windows the mvm script would be a symbolic link to a single file</span><br><span></span><br><span>Note that using the makefiles approach eliminates the separate build directories for production, assert & debug VMs</span><br><span></span><br><span></span><br><span>(*) rewriting the Mac OS build system to use makefiles was the path of least resistance when adding building of 64-bit Spur VMs because Xcode project files offer no abstraction and no sharing and are much much worse to edit than the Linux mvm scripts</span><br><span></span><br><span></span><br><span>So instead of bashing the awful little bud build system can we rewrite them together follow the windows and Mac OS scheme? We would likely end up with one set of makefiles for all Linux builds apart from a separate rules file (compilation flags etc) per platform per word size. And of course there would be a single mvm script and one would never need to run autoconfig and hence get the phase errors that result from some settings between my made when configure gets built, said me getting made when configure is run and yet others being made when make is run.</span><br><span></span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>* One would need to pass CC to configure and make</span><br></blockquote><blockquote type="cite"><span>* But even for configure CC=clang seems to go missing (<a href="https://api.travis-ci.org/v3/job/361174043/log.txt">https://api.travis-ci.org/v3/job/361174043/log.txt</a>): "checking whether gcc -std=gnu99 is Clang... no"</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Try executing the script with shell tracing on "sh -x ./build..." and see if CC is being passed a long? And cat config.log to see which compiler was used during the configuration step?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>[1] I have worked with ARM, MIPS, PowerPC, x86 CPUs in my career and I know no other project that needs such build scripts to support different architectures and build flags...</span><br></blockquote></div></blockquote></body></html>