[Vm-dev] Re: updating configure.ac

Sat Oct 8 05:27:12 UTC 2016

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/2
>> 016-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
>

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