<div dir="ltr">I was able to build on OSX, Win, and Linux with CMake tools.<div><br></div><div>Makes much more sense than autoconf/make crap.</div><div><br></div><div>Let&#39;s not go there.</div><div><br></div><div>Phil</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 16, 2016 at 8:41 PM, Esteban Lorenzano <span dir="ltr">&lt;<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 16 Oct 2016, at 20:33, Tobias Pape &lt;<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>&gt; wrote:</div><br class="m_-8340821024755460650Apple-interchange-newline"><div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">On 16.10.2016, at 20:27, Esteban Lorenzano &lt;</span><a href="mailto:estebanlm@gmail.com" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">estebanlm@gmail.com</a><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">&gt; wrote:</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><br><blockquote type="cite">On 16 Oct 2016, at 20:03, Ben Coman &lt;<a href="mailto:btc@openInWorld.com" target="_blank">btc@openInWorld.com</a>&gt; wrote:<br><br><br>On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido<br>&lt;<a href="mailto:gerardo.santana@gmail.com" target="_blank">gerardo.santana@gmail.com</a>&gt; wrote:<br><blockquote type="cite"><br>I would like to get more feedback regarding the summary I posted a week ago. Reverse engineering configure to get <a href="http://configure.ac" target="_blank">configure.ac</a> has meant a lot of work (see my progress attached) yet I still believe this step is crucial to tidy up our build system and add new platforms more easily, by adding more and *better* tests to <a href="http://configure.ac" target="_blank">configure.ac</a>.<br><br>Please let me know if there&#39;s any interest on this or whether you want to follow a different approach.<br><br>On Sat, Oct 8, 2016 at 12:27 AM, Gerardo Santana Gómez Garrido &lt;<a href="mailto:gerardo.santana@gmail.com" target="_blank">gerardo.santana@gmail.com</a>&gt; wrote:<br><blockquote type="cite"><br>To summarize it:<br><br>1. use simple, hand tailored, GNU Makefiles for building<br>2. generate and distribute a config.h once per platform<br>3. re-generate them only when a new platform is added or a current platform has had significant changes<br><br>For #3 to happen we need a configure script to do it. New platforms or changes to current ones will certainly mean adding tests to the configure script and so we also need <a href="http://configure.ac" target="_blank">configure.ac</a>, for maintaining it.<br><br>Sadly, it seems that the configure script was being generated and checked into the source tree without the corresponding <a href="http://configure.ac" target="_blank">configure.ac</a>. FYI, I&#39;m working on reverse engineering it to get the original <a href="http://configure.ac" target="_blank">configure.ac</a>. After that it will be easy to move to where we want to be.<br><br><br>On Wed, Oct 5, 2016 at 8:38 PM, Gerardo Santana Gómez Garrido &lt;<a href="mailto:gerardo.santana@gmail.com" target="_blank">gerardo.santana@gmail.com</a>&gt; wrote:<br><blockquote type="cite"><br>Yes, makes sense. Thanks. I will work on simplify it, based on your directives.<br><br>On Tue, Oct 4, 2016 at 2:16 PM, Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt; wrote:<br><blockquote type="cite"><br>Hi Gerardo,<br><br>On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido &lt;<a href="mailto:gerardo.santana@gmail.com" target="_blank">gerardo.santana@gmail.com</a>&gt; wrote:<br><blockquote type="cite"><br>Yes, energy and will.<br><br>Actually I would like to keep autoconf. I found out some duplicated code in the build.* directories that could probably be solved by using the autotools properly.<br><br>Are you strongly opposed to using autotools? May I try to make it work?<br></blockquote><br><br>No, I&#39;m not.  I&#39;m opposed to running it on each build.  The scheme we&#39;ve agreed upon is as follows (and I&#39;m cc&#39;ing vm-dev to include others working on this):<br><br>1. The correct realm for autoconf is in determining what facilities the platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc.  So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h.<br><br>2. the VM is to be configured from config.h (which informs us as to what third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.<wbr>spur/Makefile), and <a href="http://plugins.int" target="_blank">plugins.int</a> and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries).<br><br>So the build scheme we&#39;re trying to move towards is<br><br>a) either autoconf or CMake is used to generate a config.h file in each build directory that defines platform facilities (#define HAS_EPOLL 1 et al).  This is run occasionally, /not/ on every build<br><br>b) use conventional Gnu Make makefiles, avoiding all the mkmf scripts in platforms/unix/conf, to build specific VMs<br><br>Does that make sense?  For me this is very important.  See<br><br><a href="http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-February/119002.html" target="_blank">http://lists.pharo.org/<wbr>pipermail/pharo-dev_lists.<wbr>pharo.org/2016-February/<wbr>119002.html</a><br><br>and this is from a Squeak Oversight Board discussion before we moved to githug:<br><br>&quot;It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3)).&quot;<br></blockquote></blockquote></blockquote></blockquote><br>Is the CMake approach certain, or yet to be proven?  Maybe CMake fits<br>in better than autoconf with the third party libs used by Pharo ?<br><br><blockquote type="cite">From my naive reading CMake seems a better cross platform choice than<br></blockquote>autoconf, but it seems that CMake can&#39;t separate out generating just a<br>config.h file from generating the build makefiles, a part that seems<br>not wanted.  Does anyone know any different?  I&#39;ve signed up to the<br>CMake mail list to try to clarify this.<br><br>On the flip side, most of the stuff I read about autoconf is that it<br>is very unix based and not suited for cross-platform with native<br>MSWindows MSVC.  Except an enabler might be CCCL, a gcc compatibility<br>wrapper for the MSVC command-line....<br><a href="https://github.com/swig/cccl#autotools-and-msvc" target="_blank">https://github.com/swig/cccl#<wbr>autotools-and-msvc</a><br><a href="https://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-projects-under-msvc-part-one/" target="_blank">https://folti.blogs.balabit.<wbr>com/2009/08/compiling-<wbr>autoconfmake-projects-under-<wbr>msvc-part-one/</a><br><br><br>What is the future of (IIUC) Pharo&#39;s dynamic generation of Cmake files?<br></blockquote><br>in my talk with Eliot, config.h (named cogConfig.h) generation will be moved to one or the other, the one that is easier. There was not a “use this” decision.<span class="m_-8340821024755460650Apple-converted-space"> </span><br>today, I’m more closer to the opinion of using autoconf instead cmake. Main reason is that we already use autoconf for linux so why add yet-another-tool?<br></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Sorry, but CMake has been used since 2006 for the Interpreter VM on Linux replacing Autoconf there…</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">CMake is much less convoluted than Autoconf.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div><div>Well, the VM we use uses autoconf for building linux, I didn’t see any CMake. </div><div>In Pharo branch, we use CMake, so *in theory* I should prefer CMake over Autoconf. Now… I&#39;m also a fan of keeping things as simple as possible, that’s why I would think carefully before introducing a new tool… (I do not know interpreter side).</div><div><br></div><div>And CMake being less convoluted than Autoconf… well, I’m not so sure, I suffered a lot both of them :)</div><div><br></div><div>Esteban</div><br><blockquote type="cite"><div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>anyway, that’s what I have from my side. Not squeak board but pharo board :)<br><br>Esteban<br><br><blockquote type="cite"><br><br><br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br><br><br><br><blockquote type="cite"><br>On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt; wrote:<br><blockquote type="cite"><br>Hi Gerardo,<br><br> welcome!<br><br>On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido &lt;<a href="mailto:gerardo.santana@gmail.com" target="_blank">gerardo.santana@gmail.com</a>&gt; wrote:<br><blockquote type="cite"><br>Hi Eliot,<br><br>what is the proper way to ask questions regarding building Clog?<br><br>I just found that in opensmalltalk-vm/platforms/<wbr>unix/config, configure is not in sync with <a href="http://configure.ac" target="_blank">configure.ac</a><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><br>I guess this observation comes from generating configure from<br><a href="http://configure.ac" target="_blank">configure.ac</a> and finding a difference with the committed configure.<br><br>But I see the history date on these files seems in sync<br><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix/config/configure.ac" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm/commits/Cog/platforms/unix/<wbr>config/configure.ac</a><br><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix/config/configure" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm/commits/Cog/platforms/unix/<wbr>config/configure</a><br><br>so maybe its down to different environments?<br><br><br>I see your version on the right here...<br><a href="https://www.diffchecker.com/jAQEeQOn" target="_blank">https://www.diffchecker.com/<wbr>jAQEeQOn</a>    (valid 1 month only)<br>has this different...<br> AC_DEFUN([AC_ICONV], [<br> AC_CHECK_FUNC(_dyld_present,[<wbr>],[<br> AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [<br> AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no)<br> ])<br> if test $ac_cv_iconv = yes; then<br>   LIBS=&quot;$LIBS -liconv&quot;<br> fi]<br> )])<br><br>which I find in...<br><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/vm/acinclude.m4" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm/blob/Cog/platforms/unix/vm/<wbr>acinclude.m4</a><br>which is included by...<br><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/config/aclocal.m4" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm/blob/Cog/platforms/unix/<wbr>config/aclocal.m4</a><br>which seems referenced by...<br><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/config/Makefile" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm/blob/Cog/platforms/unix/<wbr>config/Makefile</a><br>but I don&#39;t really know how they all fit together.<br><br><br>btw Eliot, I see the following...<br><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/doc/HowToBuildFromSource.txt" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm/blob/Cog/platforms/unix/<wbr>doc/HowToBuildFromSource.txt</a><br>describes running configure, but I wonder how much of that from 2010<br>is still relevant today?<br><br>In fact I learnt something new in that doc, reading... &quot;by running the<br>config.status script ... is much faster than running configure all<br>over again. (In fact, make should detect any changes to the plugin<br>configuration and re-run config.status for you automatically.) Note:<br>`configure&#39; doesn&#39;t actually create any files. The last thing it does<br>is run `config.status&#39; to create the configured files in blddir from<br>the corresponding file.ins in the unix/config directory.<br><br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br><br>It may or may not be.  Currently I can only reliably run make to generate a new configure script on CentOS 5.3.  If I try on e.g. 6.x I get an invalid configure.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><br>Eliot, How do you determine its an invalid configure file?<br>I just ran &#39;make&#39; in  platforms/unix/config without error, although<br>the diff lines is 40k.<br><br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">We hope to eliminate configure soon and use a makefile style similar to the Mac and Windows platforms.  Do you have energy to contribute to this?<br><br><blockquote type="cite"><br><br>Thanks in advance.<br><br>P. S. I have made squeak.clog.spur compile on OpenBSD, but I&#39;m looking for a better way to do it.</blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></div></blockquote></div><br></div><br></blockquote></div><br></div>