| 1 |
* Al <oss.elmar@××××××××××.com> wrote: |
| 2 |
|
| 3 |
> * gcc covers the linker |
| 4 |
|
| 5 |
The 'gcc' command is a wrapper for several toolchain commands, |
| 6 |
from the actual compilers and assemblers down to linker. |
| 7 |
Yes, it's debatable whether that's really the recommended way (tm), |
| 8 |
but obviously it seems to be quite comfortable. |
| 9 |
|
| 10 |
(Note that the several toolchain components normally belong |
| 11 |
together quite strictly and have to be built in a way so they |
| 12 |
play along fine together. That also includes libc). |
| 13 |
|
| 14 |
> * libtool covers gcc and ar |
| 15 |
|
| 16 |
Not particularily well. It's not really a wrapper, at least no |
| 17 |
abstraction whatsoever, but more a command line filter doing |
| 18 |
certain (quite unpredictable) magic things. I'd instead suggest |
| 19 |
a real abstraction. |
| 20 |
|
| 21 |
> * makefile configures it all |
| 22 |
|
| 23 |
Not perfect, but quite fine. |
| 24 |
|
| 25 |
> * to unburden from makefile writing, it is generated by configure |
| 26 |
|
| 27 |
Actually, completely unncessary. It would be much cleaner to |
| 28 |
let it just generate some makefile include for the configuration |
| 29 |
stuff and maybe provide a library of generic make rules. |
| 30 |
|
| 31 |
> * configure is needed to be generated from configure.in |
| 32 |
|
| 33 |
When you're going into the autotools hell. Also completely |
| 34 |
obsoleted before it even came into existence. A set of well- |
| 35 |
designed shell functions could do the job *much* better. |
| 36 |
|
| 37 |
> * now there comes ebuild as the next wrapper to make building easier |
| 38 |
|
| 39 |
Not just "easier", it essentially states where how to get the |
| 40 |
sources, which different build configurations are provided and |
| 41 |
glues that to the individual package's build scripts. |
| 42 |
|
| 43 |
Yes, there could be more generic approaches, eg. maintaining |
| 44 |
the whole (already-patched) source in a canonical repository |
| 45 |
scheme (see OSS-QM), having the package provide it's switches |
| 46 |
and depencies in a purely declarative way (see Briegel), etc. |
| 47 |
|
| 48 |
> How many languages are involved only to generate and install a C |
| 49 |
> program! Maschine code, C, bash, m4, python, ... what else? How much |
| 50 |
> knowlege is needed to debug this huge stack! |
| 51 |
|
| 52 |
The stack can be coped layer-by-layer. If you'd somehow manage |
| 53 |
to get Gentoo devs (along w/ other distro's maintainers) to |
| 54 |
adopt the oss-qm project, the stack would only start at the |
| 55 |
ebuild level (since everything beyond will be provided by |
| 56 |
oss-qm and checked/tested eccessively) ;-) |
| 57 |
|
| 58 |
|
| 59 |
cu |
| 60 |
-- |
| 61 |
---------------------------------------------------------------------- |
| 62 |
Enrico Weigelt, metux IT service -- http://www.metux.de/ |
| 63 |
|
| 64 |
phone: +49 36207 519931 email: weigelt@×××××.de |
| 65 |
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 |
| 66 |
---------------------------------------------------------------------- |
| 67 |
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme |
| 68 |
---------------------------------------------------------------------- |
Archives