[Vm-dev] Re: updating configure.ac

Eliot Miranda eliot.miranda at gmail.com
Tue Oct 4 19:16:18 UTC 2016


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))."





> 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
>>>
>>
>> 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.  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.
>>>
>>> --
>>> Gerardo Santana
>>>
>>
>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>
>
>
> --
> Gerardo Santana
>



-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161004/cc92f8f2/attachment-0001.htm


More information about the Vm-dev mailing list