Ok,
I'm trying to read between the lines here so correct me if I
mis-interperted something:
Robert - You recommend we drop the autotools and fix the current build
system to handle your bullet points (plus what Scott added). The only
other thing I would add are:
* It needs to be able to clean up behind itself with regard to
object/bin/dependancies;
* Handle dependancy tracking better - it doesn't always get them
right.
Scott - Your point is to pick one build system and fix it. Autotools
is probably the better choice (article) and would address issues others
have had trying to port to different environments.
A lot of autotools "issues" have already been fixed in the source over
the last 6 months where header files tried to include config.h and some
strange dependencies on order includes in other projects. This is good.
I'm all for autotools but that is what I use every day at work although
ours are usually not real complicated in terms of compatibility and
options because they are internal. I've worked around issues in the
current build system but I'm probably not the only one. If I hadn't
already been running for 8 months prior to the reorg I probably
wouldn't have spent the time to find the issues with bdb when it
crashed.
Alan H, Scott G, David B, Derek, Jason, Robert S (sorry if I missed any
key people):
- If we fix/finish autotools, will you take it?
- What bar do we have to meet for it to be "the" build system?
- What restrictions do you want to add?
- What additional issues would you like to add to see resolved?
Thanks,
Jay
Scott Lawrence wrote:
On Mon, 2005-10-10 at 12:33 -0500, Robert Sparks wrote:
Jay -
I've pretty much given up on an autotools based parallel build system.
While there are a few things that it does that the custom build
system doesn't do,
the warts that come with it appear to be too much for most of this
development
community to live with. I'm going to try to see if putting effort
into getting it to do
those things will pay off better than trying to maintain the extra
build system.
Among those are:
+ being able to build separate pieces of the project independently,
leveraging
other parts that may already be built. (The current notion of all
the projects having
to live in particular relative places in the filesystem is
something we need to address).
+ being able to configure against different instances of third party
dependencies.
(such as different versions of bdb as you were running into below).
This needs to be scriptable (being able to specify everything on
the configure
command line is sufficient).
+ making sure that the resulting built libraries can be _used_ from
other autotools
based projects without having to "install" them.
What else is missing from your perspective?
- Detecting when dependencies are missing or the wrong version.
- Not using libtool to build shared libraries
This is useful because a libtool library carries metadata with it.
If library B uses library A, I can just declare that I'm using B
and it will take care of making sure that any flags needed for A
are included.
I'm more than willing to help with any autotools issues, but I agree
that it's probably pointless to shift if you're going to try to maintain
it as a parallel system.
FYI - an interesting selection from a list of reasons why open source
projects don't get wide participation:
http://www.openxource.com/crossings/2004/11/21/antipattern_ignore_established_tools/brief
|