[Vm-dev] updating configure.ac

phil at highoctane.be phil at highoctane.be
Sun Oct 16 19:35:39 UTC 2016


I was able to build on OSX, Win, and Linux with CMake tools.

Makes much more sense than autoconf/make crap.

Let's not go there.

Phil

On Sun, Oct 16, 2016 at 8:41 PM, Esteban Lorenzano <estebanlm at gmail.com>
wrote:

>
>
> On 16 Oct 2016, at 20:33, Tobias Pape <Das.Linux at gmx.de> wrote:
>
>
>
> On 16.10.2016, at 20:27, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>
>
>
> On 16 Oct 2016, at 20:03, Ben Coman <btc at openInWorld.com> wrote:
>
>
> On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido
> <gerardo.santana at gmail.com> wrote:
>
>
> I would like to get more feedback regarding the summary I posted a week
> ago. Reverse engineering configure to get configure.ac 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 configure.ac.
>
> Please let me know if there's any interest on this or whether you want to
> follow a different approach.
>
> On Sat, Oct 8, 2016 at 12:27 AM, Gerardo Santana Gómez Garrido <
> gerardo.santana at gmail.com> wrote:
>
>
> To summarize it:
>
> 1. use simple, hand tailored, GNU Makefiles for building
> 2. generate and distribute a config.h once per platform
> 3. re-generate them only when a new platform is added or a current
> platform has had significant changes
>
> 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 configure.ac, for maintaining it.
>
> Sadly, it seems that the configure script was being generated and checked
> into the source tree without the corresponding configure.ac. FYI, I'm
> working on reverse engineering it to get the original configure.ac. After
> that it will be easy to move to where we want to be.
>
>
> On Wed, Oct 5, 2016 at 8:38 PM, Gerardo Santana Gómez Garrido <
> gerardo.santana at gmail.com> wrote:
>
>
> Yes, makes sense. Thanks. I will work on simplify it, based on your
> directives.
>
> On Tue, Oct 4, 2016 at 2:16 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>
> Hi Gerardo,
>
> On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido <
> gerardo.santana at gmail.com> wrote:
>
>
> Yes, energy and will.
>
> 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.
>
> Are you strongly opposed to using autotools? May I try to make it work?
>
>
>
> 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):
>
> 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.
>
> 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.spur/Makefile),
> and plugins.int 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).
>
> So the build scheme we're trying to move towards is
>
> 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
>
> b) use conventional Gnu Make makefiles, avoiding all the mkmf scripts in
> platforms/unix/conf, to build specific VMs
>
> Does that make sense?  For me this is very important.  See
>
> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-February/
> 119002.html
>
> and this is from a Squeak Oversight Board discussion before we moved to
> githug:
>
> "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))."
>
>
> Is the CMake approach certain, or yet to be proven?  Maybe CMake fits
> in better than autoconf with the third party libs used by Pharo ?
>
> From my naive reading CMake seems a better cross platform choice than
>
> autoconf, but it seems that CMake can't separate out generating just a
> config.h file from generating the build makefiles, a part that seems
> not wanted.  Does anyone know any different?  I've signed up to the
> CMake mail list to try to clarify this.
>
> On the flip side, most of the stuff I read about autoconf is that it
> is very unix based and not suited for cross-platform with native
> MSWindows MSVC.  Except an enabler might be CCCL, a gcc compatibility
> wrapper for the MSVC command-line....
> https://github.com/swig/cccl#autotools-and-msvc
> https://folti.blogs.balabit.com/2009/08/compiling-
> autoconfmake-projects-under-msvc-part-one/
>
>
> What is the future of (IIUC) Pharo's dynamic generation of Cmake files?
>
>
> 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.
> 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?
>
>
> Sorry, but CMake has been used since 2006 for the Interpreter VM on Linux
> replacing Autoconf there…
> CMake is much less convoluted than Autoconf.
>
>
> Well, the VM we use uses autoconf for building linux, I didn’t see any
> CMake.
> In Pharo branch, we use CMake, so *in theory* I should prefer CMake over
> Autoconf. Now… I'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).
>
> And CMake being less convoluted than Autoconf… well, I’m not so sure, I
> suffered a lot both of them :)
>
> Esteban
>
>
>
> anyway, that’s what I have from my side. Not squeak board but pharo board
> :)
>
> Esteban
>
>
>
>
>
>
>
>
>
>
> On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>
> Hi Gerardo,
>
>  welcome!
>
> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido <
> gerardo.santana at gmail.com> wrote:
>
>
> Hi Eliot,
>
> what is the proper way to ask questions regarding building Clog?
>
> I just found that in opensmalltalk-vm/platforms/unix/config, configure is
> not in sync with configure.ac
>
>
> I guess this observation comes from generating configure from
> configure.ac and finding a difference with the committed configure.
>
> But I see the history date on these files seems in sync
> https://github.com/OpenSmalltalk/opensmalltalk-
> vm/commits/Cog/platforms/unix/config/configure.ac
> https://github.com/OpenSmalltalk/opensmalltalk-
> vm/commits/Cog/platforms/unix/config/configure
>
> so maybe its down to different environments?
>
>
> I see your version on the right here...
> https://www.diffchecker.com/jAQEeQOn    (valid 1 month only)
> has this different...
>  AC_DEFUN([AC_ICONV], [
>  AC_CHECK_FUNC(_dyld_present,[],[
>  AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [
>  AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no)
>  ])
>  if test $ac_cv_iconv = yes; then
>    LIBS="$LIBS -liconv"
>  fi]
>  )])
>
> which I find in...
> https://github.com/OpenSmalltalk/opensmalltalk-
> vm/blob/Cog/platforms/unix/vm/acinclude.m4
> which is included by...
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/
> config/aclocal.m4
> which seems referenced by...
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/
> config/Makefile
> but I don't really know how they all fit together.
>
>
> btw Eliot, I see the following...
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/
> doc/HowToBuildFromSource.txt
> describes running configure, but I wonder how much of that from 2010
> is still relevant today?
>
> In fact I learnt something new in that doc, reading... "by running the
> config.status script ... is much faster than running configure all
> over again. (In fact, make should detect any changes to the plugin
> configuration and re-run config.status for you automatically.) Note:
> `configure' doesn't actually create any files. The last thing it does
> is run `config.status' to create the configured files in blddir from
> the corresponding file.ins in the unix/config directory.
>
>
>
>
> 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.
>
>
> Eliot, How do you determine its an invalid configure file?
> I just ran 'make' in  platforms/unix/config without error, although
> the diff lines is 40k.
>
>
> 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?
>
>
>
> Thanks in advance.
>
> P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm looking for
> a better way to do it.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161016/bf292ac5/attachment-0001.htm


More information about the Vm-dev mailing list