[Vm-dev] Re: updating configure.ac

Gerardo Santana Gómez Garrido gerardo.santana at gmail.com
Thu Oct 6 01:38:09 UTC 2016


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



-- 
Gerardo Santana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161005/b626d42c/attachment-0001.htm


More information about the Vm-dev mailing list