* Al <oss.el...@googlemail.com> wrote:
> Somehow I don't really like the way it is done. The levels of
> abstraction are mixed and it results in very cryptic parameters.
Yes. Historically grown.
I've did a little proof-of-concept for developing an generic
abstraction of toolchain operations in the unitool project:
git://pubgit.metux.de/projects/unitool.git
> > 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.
Well, but it's quite good for the jobs it was invented for.
I've did some experiments on generalizing typical configure
script stuff into shell functions, which works quite well.
That's the way I'd suggest for the future.
A completely different idea would be completely dropping the
imperative and process-driven approach in favour of an declarative
model, which just describes the structure of an software component.
git://pubgit.metux.de/projects/treebuild.git
> 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.
Yes. And truely, some ebuilds do things they IMHO shouldnt do.
For example, ebuilds should _never_ change source trees arbitrarily,
instead just have a defined set of patches (independent from useflags)
against the original sourcetree.
But that's a problem of some individual ebuilds, not emerge in general.
> 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.
Most of these issues should _not_ be mixed onto several layers,
that's one of the major problems, upstream's misdesign, tolerated
by downstreams/distros ;-P
> 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.
You just need access to all layers and test from buttom up.
> 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.
There should only be exactly _one_ place for applying patches:
a QM layer in the middle between upstream release and distro's
package management. And now we're at the OSS-QM project again ;-p
> 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.
The problem here is that there's now common QM layer of Gentoo
*and* Cygwin (and other distros), between upstream and distros.
And here we see a typical problem: individual distros tend to do
only distro-specific patches, which often are not upstream-capable,
instead of _generic_ fixes.
Again: OSS-QM ;-p
> 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?
Yes, that's exactly the primary goal of it.
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
----------------------------------------------------------------------
