* Al <oss.el...@googlemail.com> wrote: > * gcc covers the linker
The 'gcc' command is a wrapper for several toolchain commands, from the actual compilers and assemblers down to linker. Yes, it's debatable whether that's really the recommended way (tm), but obviously it seems to be quite comfortable. (Note that the several toolchain components normally belong together quite strictly and have to be built in a way so they play along fine together. That also includes libc). > * libtool covers gcc and ar Not particularily well. It's not really a wrapper, at least no abstraction whatsoever, but more a command line filter doing certain (quite unpredictable) magic things. I'd instead suggest a real abstraction. > * makefile configures it all Not perfect, but quite fine. > * to unburden from makefile writing, it is generated by configure Actually, completely unncessary. It would be much cleaner to let it just generate some makefile include for the configuration stuff and maybe provide a library of generic make rules. > * configure is needed to be generated from configure.in When you're going into the autotools hell. Also completely obsoleted before it even came into existence. A set of well- designed shell functions could do the job *much* better. > * now there comes ebuild as the next wrapper to make building easier Not just "easier", it essentially states where how to get the sources, which different build configurations are provided and glues that to the individual package's build scripts. Yes, there could be more generic approaches, eg. maintaining the whole (already-patched) source in a canonical repository scheme (see OSS-QM), having the package provide it's switches and depencies in a purely declarative way (see Briegel), etc. > How many languages are involved only to generate and install a C > program! Maschine code, C, bash, m4, python, ... what else? How much > knowlege is needed to debug this huge stack! The stack can be coped layer-by-layer. If you'd somehow manage to get Gentoo devs (along w/ other distro's maintainers) to adopt the oss-qm project, the stack would only start at the ebuild level (since everything beyond will be provided by oss-qm and checked/tested eccessively) ;-) cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------
