On Tue, 14 Feb 2006 15:47:30 +0100 I. Szczesniak wrote:
> On 2/14/06, Gunnar Ritter <gunnarr at acm.org> wrote:
> > I doubt that. ksh93 has bugs on its own. Sun will have the choice to
> > either wait for an upstream bug fix or to get its engineers to handle
> > it in-house. But then, have a look at the ksh93 source code. In case
> > the ksh88 code should really be a nightmare, what is the ksh93 code
> > with its close integration to large libraries such as libast and its
> > very special build environment?

> Invalid arguments.
> The build system can be worked around or fixed as in MacOS X. libast
> may be statically linked if it does not make sense to make it a public
> API. The only thing which is likely going to be exposed is libshell.

the build system from our end is capable of generating alternate build
systems for outside use (e.g., bootstrap build, weird setups like cygwin)

it would be possible to generate old make makefiles with whatever extra
stuff you need to please your build system -- it won't be as reliable
a development environment as we use everyday, but that's the alternate
build system's problem

the build system we use also has to be taken into context

it handles all source and multi-target binaries (including coexisting
-g|-p|-O* alternate compilations) in a single directory tree

it separates source from generated files -- you always know what files
may be overwritten on the next build -- try to figure that out
with auto*

it handles parallel/remote builds

it determines the build order by examining Makefiles

it handles native dll/sharedlib generation and execution time loading
on all target architectures

it generates source and binary packages that, with one command,
can replicate itself on other systems

it generates bootstrap scripts for systems that don't have the build system

the latter gets the most complexity/weirdness complaints

if the build system becomes a sticking point then let the messages fly

finally, on the ksh93 side there are 3 people involved,
the same ones since 1984 (for me), earlier for dgk and Phong Vo 
(sfio,cdt,vmalloc)

that has given us the luxury of a high level of integration between commands 
and libraries


Reply via email to