<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 16, 2016 at 8:33 PM, Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 16.10.2016, at 20:27, Esteban Lorenzano <<a href="mailto:estebanlm@gmail.com">estebanlm@gmail.com</a>> wrote:<br>
<br>
><br>
><br>
>> On 16 Oct 2016, at 20:03, Ben Coman <btc@openInWorld.com> wrote:<br>
>><br>
>><br>
>> On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido<br>
>> <<a href="mailto:gerardo.santana@gmail.com">gerardo.santana@gmail.com</a>> wrote:<br>
>>><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" rel="noreferrer" 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" rel="noreferrer" target="_blank">configure.ac</a>.<br>
>>><br>
>>> Please let me know if there'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 <<a href="mailto:gerardo.santana@gmail.com">gerardo.santana@gmail.com</a>> wrote:<br>
>>>><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" rel="noreferrer" 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" rel="noreferrer" target="_blank">configure.ac</a>. FYI, I'm working on reverse engineering it to get the original <a href="http://configure.ac" rel="noreferrer" 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 <<a href="mailto:gerardo.santana@gmail.com">gerardo.santana@gmail.com</a>> wrote:<br>
>>>>><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 <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Hi Gerardo,<br>
>>>>>><br>
>>>>>> On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido <<a href="mailto:gerardo.santana@gmail.com">gerardo.santana@gmail.com</a>> wrote:<br>
>>>>>>><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>
>>>>>><br>
>>>>>><br>
>>>>>> No, I'm not. I'm opposed to running it on each build. The scheme we've agreed upon is as follows (and I'm cc'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" rel="noreferrer" 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'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" rel="noreferrer" 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>
>>>>>> "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))."<br>
>><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>
>>> From my naive reading CMake seems a better cross platform choice than<br>
>> autoconf, but it seems that CMake can'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'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" rel="noreferrer" 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/" rel="noreferrer" 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's dynamic generation of Cmake files?<br>
><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.<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>
<br>
Sorry, but CMake has been used since 2006 for the Interpreter VM on Linux replacing Autoconf there…<br>
CMake is much less convoluted than Autoconf.<br></blockquote><div><br></div><div>+ 1000</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> anyway, that’s what I have from my side. Not squeak board but pharo board :)<br>
><br>
> Esteban<br>
><br>
>><br>
>><br>
>><br>
>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>>><br>
>>>>>>> On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
>>>>>>>><br>
>>>>>>>> Hi Gerardo,<br>
>>>>>>>><br>
>>>>>>>> welcome!<br>
>>>>>>>><br>
>>>>>>>> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido <<a href="mailto:gerardo.santana@gmail.com">gerardo.santana@gmail.com</a>> wrote:<br>
>>>>>>>>><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" rel="noreferrer" target="_blank">configure.ac</a><br>
>><br>
>> I guess this observation comes from generating configure from<br>
>> <a href="http://configure.ac" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" 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="$LIBS -liconv"<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" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm/blob/Cog/platforms/unix/<wbr>config/Makefile</a><br>
>> but I don'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" rel="noreferrer" 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... "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' doesn't actually create any files. The last thing it does<br>
>> is run `config.status' to create the configured files in blddir from<br>
>> the corresponding file.ins in the unix/config directory.<br>
>><br>
>><br>
>>>>>>>><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>
>><br>
>> Eliot, How do you determine its an invalid configure file?<br>
>> I just ran 'make' in platforms/unix/config without error, although<br>
>> the diff lines is 40k.<br>
>><br>
>><br>
>>>>>>>> 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>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> Thanks in advance.<br>
>>>>>>>>><br>
>>>>>>>>> P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm looking for a better way to do it.<br>
<br>
<br>
</blockquote></div><br></div></div>