Subject: Re: peer libraires
From: Paul Rohr (paul@abisource.com)
Date: Tue Aug 21 2001 - 15:54:23 CDT
At 10:23 PM 8/21/01 CEST, Stephane Fritsch wrote:
>I can't wait to read about these topics. I am trying to keep the BeOS
>build
>in sync but I had many toubles building libiconv. And BeOS isn't the
>only
>affected platform according to the posts here.
Thanks for trying to revive the BeOS builds. I've really hated to see it
falling behind.
>Why are we trying to supply our own Makefiles for peer libraries ? Do
>we really need a specific build for these libraries ? The default
>building
>procedure looks fine to me and it seems to be much more XP than our
>makefile. And it just works.
I think that there's an evolving consensus that finding ways to use native
XP makefiles instead of our own is a Good Thing. The fewer makefiles the
better, I think we'd all agree.
I can't speak for each library, but historically, there seem to have been a
few different kinds of obstacles here.
1. Over-dependence on autoconf in the "original" makefiles. This is less
and less of a problem as various configure wizards have learned how to
coerce various packages' configured makefiles (EXPAT, PSICONV) into building
using our supported toolchain.
2. Difficulty adapting more "standard" make systems to generate variants of
the library that we can easily link with. For example, we sometimes only
needed part of a package, and thus it was easier to trim down our own
makefiles than patch the stock makefiles.
3. Philosophical/practical. IIRC, we had a debate early on about what'd be
the easiest way to ensure that a make in the abi/src tree would also detect
and trigger builds of the peers as needed. For example, we wanted automated
ways to make sure that "make realclean; make" in the abi directory would
*guarantee* that we'd get pristine builds of everything.
You'll note that Jeff's solution of building *all* object files, libraries,
and binaries in a single abi/src subtree makes it really easy to ensure that
they all get blown away properly, and that there aren't any debug/release
collisions. ;-)
4. Sheer lack of time. For example, I made the diving make thing work for
libiconv 1.7 on Win32 because it was just easier for me than reading through
and understanding all the directions Bruno ships with. I wish I'd had time
to learn how to use his configured makefiles instead, but that's too much
wizardry for the amount of time I had (ie, none).
bottom line
-----------
Insofar as anyone has the time to switch individual peer libraries from our
XP makefiles to the package's XP makefiles, that'd be great, so long as they
help do the work to get the new approach to Just Build on the remaining
platforms as well.
I'm afraid that this is the kind of work that most of us find tremendously
unappealing, and only marginally rewarding.
Paul
This archive was generated by hypermail 2b25 : Tue Aug 21 2001 - 15:46:30 CDT