Glenn Fowler <gsf at research.att.com> 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 ..."
I thought this kind of discussions have been closed more than 3 years ago,
when the basic discussions for star integration have been finitshed.
There is no "dead code" in star nor cdrecord and I am 100% sure the same
applies to ksh93.
What we did negotiate at that time was that as Sun does not like dynamic
autoconfiguration, someone at Sun needs to run the official compile environment
from time to time and needs to make sure that the autoconfiguration results
are made available to the ON build environment and not outdated.
> 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
This is what the Schily makefile system grants and what the ATT sytstem
grants too. I understand that people have an aversion against the build
system as propagandized by the FSF because it usually needs manual intervention
in order to build successfully. But there is a really working build system
that just does what you like when you call "make" is different.
> "opensolaris lets you write beautiful code"
>
> ... that most likely would be stuck in opensolaris or would
> require configuration for other systems, *including posix*
If this topic is brought on the table, I need to say that a lot of
the utility sources from ON are not really written cleanly and will
not compile on all POSIX platforms. If someone likes to discuss your or my
portable software and the way portability is achieved, we should first discuss
the bugs and coding style in OS's usr/src/cmd/*.
You either take a portable program/framework as it is or it is completely up to
you to make if compile in your environment.
> are any GNU components in ON? perl? emacs?
>
> 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
> (2) validating that the package+configure is the same as package-configure
I am not sure about what you did in the past monts, I did rework my schily
makefilesystem in a way that allows to run "make install" and this will
besides others install /usr/include/schily/*.h as well as the autoconf results
into e.g. /usr/include/schily/i386-sunos5-cc/xconfig.h ...
You of course need to do this on a native machine as a lot of the autoconf
tests try to run test code on the machine in order to retrieve platform related
results.
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
