Re: [gentoo-user] Re: Shared libraries in Gentoo

[Al]

>> * 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