[Vm-dev] updating configure.ac

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


On Sun, Oct 16, 2016 at 8:33 PM, 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.
>

+ 1000


>
> >
> > 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/90a8dd5f/attachment.htm


More information about the Vm-dev mailing list