[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: dirlist.d/ directory support

From: Stepan Kasal
Subject: Re: Proposal: dirlist.d/ directory support
Date: Mon, 28 Aug 2006 11:31:24 +0200
User-agent: Mutt/


On Fri, Aug 25, 2006 at 03:35:08AM +0200, Robert Schiele wrote:
> On Fri, Aug 25, 2006 at 02:35:26AM +0200, Stepan Kasal wrote:
> > this example is very illustrative.  I think the dirlist.d/package
> > files would contain one absolute patch each.  And that can be
> Uhm, but there might be packages that provided multiple pathes.

well, I still believe that in real life the average number of lines
for those files would be below 1.01.

> it might be true but my approach is more generic because it just
> modularizes the current dirlist feature.

More generic does not mean more adequate.

> ... well understood by most system administrators.

If I noticed that feature, I would not have problems to understand
it, I would just think that it is an ugly overkill, and ...

... as a gnome autogen user, I would say to myself, that ``they are
solving their artificial problems, while ignoring the real ones.''
[That's why I mention the issue in my previous mail, though it is
not directly connected.]

I mean this:
> > when you have /opt/gnome24 and /opt/gnome26 and want to use one of
> > them for one build and another one for another build.

> [...] Or to make my argument more objective: It was not subject of this
> design to prevent people from doing stupid things but to make it easier for
> them doing the right thing.

This is exactly what I meant; the above requirement is very natural,
at least for Gnome developpers, and Automake does not help with this

I do not want to go into details, but it seems that the most natural
solution for their problem would be to set something like
ACLOCAL_FLAGS="-I /opt/gnome24/share/aclocal" or
ACLOCAL_ADDPATH=/opt/gnome24/share/aclocal  for the builds which
are supposed to use the older version of Gnome and another option for
the builds with "new" macros.

But aclocal does not support anything like this, so they are forced
to use the command-line option -I.  So their `'
passes variable ACLOCAL_FLAGS to aclocal.

The fact that `autogen understands ACLOCAL_FLAGS but aclocal does
not', and the unrelated feature of `ACLOCAL_AMFLAGS in'
brings much confusion.

I see the Gnome community is not innocent, yet I believe that there
are steps which the Automake developers could do to help to clear this

> If a vendor provides packages that can be used only mutual exclusive for
> development then he has to provide a solution to make sure that a maximum of
> _one_ development package is setup for default use. [...]

I'm not sure that I deciphered the above right, yet it IMHO does not
apply here: there is no `mutual exclusivity' involved.  The reason
for using these two setups simultaneosly is that they want to support
a stable branch and work on a development one at the same time.

(BTW, have I told  you that I'm just a member of this list, and I do
not have direct influence on the fate of your proposal?)

Stepan Kasal

reply via email to

[Prev in Thread] Current Thread [Next in Thread]