1 |
* Al <oss.elmar@××××××××××.com> wrote: |
2 |
|
3 |
> Somehow I don't really like the way it is done. The levels of |
4 |
> abstraction are mixed and it results in very cryptic parameters. |
5 |
|
6 |
Yes. Historically grown. |
7 |
|
8 |
I've did a little proof-of-concept for developing an generic |
9 |
abstraction of toolchain operations in the unitool project: |
10 |
|
11 |
git://pubgit.metux.de/projects/unitool.git |
12 |
|
13 |
> > When you're going into the autotools hell. Also completely |
14 |
> > obsoleted before it even came into existence. A set of well- |
15 |
> > designed shell functions could do the job *much* better. |
16 |
> > |
17 |
> |
18 |
> The shell script terminology is a little strange, especially the |
19 |
> conditions. They differ from the style of most modern languages, |
20 |
> differ even from C. |
21 |
|
22 |
Well, but it's quite good for the jobs it was invented for. |
23 |
I've did some experiments on generalizing typical configure |
24 |
script stuff into shell functions, which works quite well. |
25 |
That's the way I'd suggest for the future. |
26 |
|
27 |
A completely different idea would be completely dropping the |
28 |
imperative and process-driven approach in favour of an declarative |
29 |
model, which just describes the structure of an software component. |
30 |
|
31 |
git://pubgit.metux.de/projects/treebuild.git |
32 |
|
33 |
> I wanted to stress how this "making easier" by another wrapper and |
34 |
> another wrapper leads finnally into kind of a debugging hell, that |
35 |
> makes matters more complicated in the end. Having different levels of |
36 |
> abstraction is fine, but they should do it in clean way without mixing |
37 |
> levels at least. |
38 |
|
39 |
Yes. And truely, some ebuilds do things they IMHO shouldnt do. |
40 |
For example, ebuilds should _never_ change source trees arbitrarily, |
41 |
instead just have a defined set of patches (independent from useflags) |
42 |
against the original sourcetree. |
43 |
|
44 |
But that's a problem of some individual ebuilds, not emerge in general. |
45 |
|
46 |
> It's clear that the overall package management is a different layer |
47 |
> from program building. However the question of portablility for |
48 |
> example is mixed into all levels, is it libtool or is it eclasses. It |
49 |
> will be similar for things like internationalization. |
50 |
|
51 |
Most of these issues should _not_ be mixed onto several layers, |
52 |
that's one of the major problems, upstream's misdesign, tolerated |
53 |
by downstreams/distros ;-P |
54 |
|
55 |
> Ideally it can. In praxis the stack can't always be coped |
56 |
> layer-by-layer by different teams. In the moment the bug is there, you |
57 |
> have to search them all. |
58 |
|
59 |
You just need access to all layers and test from buttom up. |
60 |
|
61 |
> For my target of a port I have to understand them all, up to a certain |
62 |
> degree. I have to apply patches at different layers. |
63 |
|
64 |
There should only be exactly _one_ place for applying patches: |
65 |
a QM layer in the middle between upstream release and distro's |
66 |
package management. And now we're at the OSS-QM project again ;-p |
67 |
|
68 |
> For my case that would be of help. I currently have to mix patches |
69 |
> from cygwin with patches from Gentoo. Sure that leads to conflicts. |
70 |
|
71 |
The problem here is that there's now common QM layer of Gentoo |
72 |
*and* Cygwin (and other distros), between upstream and distros. |
73 |
And here we see a typical problem: individual distros tend to do |
74 |
only distro-specific patches, which often are not upstream-capable, |
75 |
instead of _generic_ fixes. |
76 |
|
77 |
Again: OSS-QM ;-p |
78 |
|
79 |
> However it is always problematic to depend on another team and have to |
80 |
> wait for bugfixes. You must be able to bugfix yourself. Is that |
81 |
> addressed by the oss-qm? |
82 |
|
83 |
Yes, that's exactly the primary goal of it. |
84 |
|
85 |
|
86 |
cu |
87 |
-- |
88 |
---------------------------------------------------------------------- |
89 |
Enrico Weigelt, metux IT service -- http://www.metux.de/ |
90 |
|
91 |
phone: +49 36207 519931 email: weigelt@×××××.de |
92 |
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 |
93 |
---------------------------------------------------------------------- |
94 |
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme |
95 |
---------------------------------------------------------------------- |