>> * 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. >
Somehow I don't really like the way it is done. The levels of abstraction are mixed and it results in very cryptic parameters. IMHO it should be one tool with coherent parameters or two tools. In the latter case both would be controlled be the same build script. When gcc says ld it should also say ar at least. >> * 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. Similar gcc. Different tasks, different levels of abstraction are somewhat queerly mixed. Another parameter style steps in. > >> * 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. > The shell script terminology is a little strange, especially the conditions. They differ from the style of most modern languages, differ even from C. I don't like the Ant approach either, because logic doesn't fit well into XML. I would appriciate it based on a modern programming language. Then there would be lesser needs for autogeneration. >> * 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 I wanted to stress how this "making easier" by another wrapper and another wrapper leads finnally into kind of a debugging hell, that makes matters more complicated in the end. Having different levels of abstraction is fine, but they should do it in clean way without mixing levels at least. It's clear that the overall package management is a different layer from program building. However the question of portablility for example is mixed into all levels, is it libtool or is it eclasses. It will be similar for things like internationalization. Often the way it is simply exists for historical reasons. Well that is the way of open source. At that point a company like MS can make more courageous decisions of the overall design. Sometimes they make use of it. > 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 Ideally it can. In praxis the stack can't always be coped layer-by-layer by different teams. In the moment the bug is there, you have to search them all. For my target of a port I have to understand them all, up to a certain degree. I have to apply patches at different layers. > 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) ;-) For my case that would be of help. I currently have to mix patches from cygwin with patches from Gentoo. Sure that leads to conflicts. However it is always problematic to depend on another team and have to wait for bugfixes. You must be able to bugfix yourself. Is that addressed by the oss-qm? Than it seems a layer between the original sources and the own project. It adds new complexity. Is that price worth the gain? Al
