[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] Autotools build system
From: |
al davis |
Subject: |
Re: [Gnucap-devel] Autotools build system |
Date: |
Mon, 8 Jun 2009 22:44:19 -0400 |
User-agent: |
KMail/1.11.4 (Linux/2.6.26-1-amd64; KDE/4.2.4; x86_64; ; ) |
On Sunday 07 June 2009, Kevin Bowling wrote:
> I would like to fix up the autotools build system and address
> any short comings Gnucap is having. You've said before that
> it is broken or not optimal. Can you list any specific
> cases? I will post patches to the list when this work is
> complete.
How do I start on this one?
I have never seen the autotools build system really work well,
anywhere, but it seems the new alternative build systems throw
out the good parts (make) and rewrite the bad parts in another
language, so they are even worse.
In spite of that, I acknowledge the need for it, and feel that
for now there is no alternative, as I look with trepidation at
updating the gnucap autoconf system as is needed for plugins.
I have kept the old build system for two reasons .. One is as a
backup for when autotools don't work. The other is that the old
system is much nicer for development. It was never intended as
a "product" like autotools, but I think it has potential if
somebody wants to finish the job.
Basically, the old build system uses a 3-part Makefile. You cat
the 3 parts. Make1 is program specific, like the autotools
Makefile.am. Make2 customizes to the environment. It is the
piece that would be generated by a configure script, or can be
manually edited. Make3 is boiler plate. It contains things
like target definitions that never change. For it to become a
viable replacement for autotools, it would need more targets in
Make3 and more tests in the configure script. Most of this
could be copied from autotools!
What is needed now is update of both versions to properly handle
plugins. Also needed is a refactoring of code separating core,
includes, main, and plugins.
Henrik suggested making most of the core a library, with a very
minimal main program. I agree that we need to do at least what
Henrik suggested, most likely more. Since we are rearranging
anyway, it is probably appropriate to do it now.
I consider choosing which plugins to static link to be something
a regular user building the program should be able to do. This
is not supported by autotools as far as I know.
The installation needs to produce something like this:
- a main executable, installed where executables normally go.
- includes, installed where includes normally go
- plugins available system-wide, intalled like libraries.
- each plugin must be considered separately
- a simple way to build user plugins with a simple Makefile
- a place for things like spice-wrapper.cc and the plugin Make2.
Is this enough to get you started?
al.
- [Gnucap-devel] Autotools build system, Kevin Bowling, 2009/06/07
- Re: [Gnucap-devel] Autotools build system,
al davis <=
- Re: [Gnucap-devel] Autotools build system, Kevin Bowling, 2009/06/17
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/20
- Re: [Gnucap-devel] Autotools build system, al davis, 2009/06/20
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, al davis, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/21
- Re: [Gnucap-devel] Autotools build system, David Fang, 2009/06/21