On Thu, 24 Aug 2006 06:46:32 +0200 Roland Mainz wrote: > > If that is true, then it's a shame-- as a reference, how do other software > > distributions (debian, fedora, etc.) handle building a sane ksh93?
> A common practice seems to be that they patch the source and the build > system to fit their needs and/or built the RPM as "root" and shuffel > some system files around to make sure the AST build system finds them at > the expected place (for example the Debian build server seems to install > only those packages listed in the built dependicies... others simply > wrote their own makefiles (like we did) or run some other stunts. For > example the "buildksh93.ksh" script I am using to build the header files > was originally a clone of how SuSE's RPM handles the job (their solution > includes building ksh93 via the normal build system (after applying > source patches and set CCFLAGS to include some AST-specific options, > overriding the "iffe" probe system) and then parse the build log, > extract the locations of the *.o files from there and construct the > shared libraries manually from these objects)). These things are more or > less done by trial&error testing and not really by design... ;-( there's a simple way to disable iffe regeneration (1) put the solaris specific FEATURE/* in scope before the build (2) build with IFFE=":" there may be a simple way to track our system independent nmake makefile changes to system dependent /bin/make makefiles -- provide e.g. the solaris specific ksh93 Makefile and we may be able to tweak one of our makefile compatibilty generators to meet solaris requirements also note that the ast build system often gets a black eye because mamake+Mamfiles are considered the build system -- Mamfiles are generated for bootstrap builds -- from the ast viewpoint the bootstrap lasts until ast nmake builds, then it takes over using the more concise system independent Makefiles, also distributed with the source -- Glenn Fowler -- AT&T Research, Florham Park NJ --
