Glenn Fowler wrote:
> On Tue, 6 Feb 2007 11:23:17 -0800 Keith M Wesolowski wrote:
>
> "... no autoconf in ON ..."
>
>
>> It's fine for AT&T to offer components that autoconfigure if that's
>> what their customers want. There's some value in being able to get
>> some kind of hopefully useful binary out of a pile of source code on
>> HPUX, Solaris, GNU/Linux, and ConvexOS. But that's not a problem we
>> have. This is ON. We know what the environment offers, and we know
>> what interfaces are available to us. And if those change in a way we
>> don't expect, we want to know *before* a user complains about it.
>> Dead code has no place in ON, and workarounds for bugs and
>> incompatibilities in other operating systems should be present only
>> when needed to interoperate with those systems - not to build on or
>> for them.
>>
>
> "... offer autoconfigure if that's what their customers want ..."
>
> what is the context for this statement?
>
> customers want code that builds and runs without intervention
> they want it to run on all of their systems from windows through unix through
> MVS
> they want it to behave the same modulo resources on all of their systems
>
> "opensolaris lets you write beautiful code"
>
> ... that most likely would be stuck in opensolaris or would
> require configuration for other systems, *including posix*
>
> are any GNU components in ON? perl? emacs?
>
perl is. I don't think we require a full run of perl's Configure to
build the version that is ON, however.
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.)
> suppose that entry into ON requires removal of all iffe/configure
> who takes the responsibility for:
> (1) ripping out iffe/configure for each package update
>
Whoever integrates it into ON, I guess.
> (2) validating that the package+configure is the same as package-configure
>
I'm not entirely sure what you mean here. But if you mean who
guarantees that what is in ON is the same as what you'd get from
compiling a downloaded (from upstream source), my guess is "nobody".
I.e. I don't think there is a requirement that this verification hold true.
There are competing desires here:
1) have code that runs optimally on OpenSolaris
2) minimizes differences with upstream code
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
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.)
-- Garrett
> -- Glenn Fowler -- AT&T Research, Florham Park NJ --
>
> _______________________________________________
> opensolaris-code mailing list
> opensolaris-code at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
