[Vm-dev] updating configure.ac

phil at highoctane.be phil at highoctane.be
Sun Oct 16 19:33:26 UTC 2016


What's bad with CMake?
It works quite well.

Phil

On Sun, Oct 16, 2016 at 8:27 PM, 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?
>
> 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/e6f8e8ec/attachment-0001.htm


More information about the Vm-dev mailing list