bug-gnu-utils
[Top][All Lists]
Advanced

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

Re: Bug#400453: Makefile misses to clean .gmo-files in the clean target,


From: Daniel Leidert
Subject: Re: Bug#400453: Makefile misses to clean .gmo-files in the clean target, so they get never be updated after updating an .po file (fwd)
Date: Tue, 28 Nov 2006 09:38:51 +0100

Am Dienstag, den 28.11.2006, 01:01 +0100 schrieb Daniel Leidert:
> Am Montag, den 27.11.2006, 20:08 +0100 schrieb Bruno Haible:

Thinking more about my yesterdays mail, I found some things, where I was
wrong.

[..]
> I'm a little bit confused. Which situations do you mean? I guess a 'make
> install' of a package that _uses_ gettext (by a person, that needs
> those .gmo files) _needs_ a gettext installation to run it and to give
> the person the possibility to "use" these .gmo files. Don't it?

It doesn't. Ok, I found some situations. But couldn't this be handled
via macro or similar? There are also enough situations that require
gettext here and there is no need to ship .gmo files in these situations
nor to remove them too late in maintainer-clean.

[..]
> > The *.gmo files are part of the distribution, hence must not be removed by
> > "make clean". (If they did, then a user who does not have the GNU gettext
> > tools installed could not do
> > "./configure; make; make clean; make; make install".)
[..]
> But even with your argument I expect, that .gmo files are at least
> removed in distclean and not in maintainer-clean, that states:

Ok. Here I was wrong. If they "belong" to a distributed archives,
distclean shouldn't remove them. I still think, that there is no need to
distribute them. 

But considering the other paragraph, I would also really like to see the
possibility to handle this via macro too - maybe with a new macro, so I
checks can be made very simple using m4_ifdef.

ATM the current design is fairly "unusable" for me. Senseless "more
work", lost functionality and paternalism of software authors work. Of
course the old way also domineered this work in a way, others probably
didn't like. But you should have implemented a solution to support both
ways, not "the one in the past" and "the other now".

Regards, Daniel





reply via email to

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