"Garrett D'Amore" <garrett at damore.org> wrote:
> If we had to run autoconf on every package we integrate, it would do
> horrible, miserable things to build times. (I'd also suggest looking at
> NetBSD, they have a similar approach, where their GNU stuff is
> "preconfigured" in their build script, so they don't use autoconf, but
> instead provide blanket assumptions about their environment.)
With the schily makefilesystem, you need one set of autoconf results
for all my tools and a small additional set for cdda2wav. If soneone likes to
use a static prebuild setup, this would not take much effort.
> There are competing desires here:
>
> 1) have code that runs optimally on OpenSolaris
> 2) minimizes differences with upstream code
These desires do not need to compete. My tools offer optimal integration
on OpenSolaris and at the same time portability.
> These two objectives are often at odds with one another. I think that
> where automatic configuration is involved, we can find that it is easy
> to remove the calls/hooks to the autoconfiguration and provide default
> configurations, without creating very large diffs (except perhaps for
> scripts that are not used, etc.)
>
> In an ideal world, it would be possible to submit changes upstream that
> meet #1, have them integrated (perhaps as an alternate "make" target,
> for example), and thereby also meet #2. But sometimes the upstream
> source doesn't care about #1, but has other priorities, like:
>
> a) run on every platform possible
> b) minimize special cases for different platforms
See above. The main problem cases today are things like privileges(5).
Other poratbility problems can be hidden in the portability framework
and usually do not show up in the sources for a specific project.
> For code that is integrated into ON, I think these are not important,
> other than where they relate to #2 above. And I would generally give
> much higher preference to #1 than #2, when choosing elements that are to
> form part of the core ON suite. (The shell is an excellent example,
> IMO, where having some local engineering resource to maintain a
> Solaris-specific port/fork/branch can pay dividends. On the other end
> of the spectrum, having an ON-specific fork of the GNU info(1) command
> seems pointless.)
GNU info is not needed as it is possible to convert the content into
standard man pages. But this is a different story.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
