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 01:01:48 +0100

Am Montag, den 27.11.2006, 20:08 +0100 schrieb Bruno Haible:
> Daniel Leidert <address@hidden> wrote:
> > It seems, the .gmo files are cleaned in the maintainer-clean target. But
> > they are created during make and so have to be cleaned in the
> > clean-target [1].
> 
> The text you cite is a heuristic list of rules of thumb. A more important
> text are the GNU Coding Standards, which say:
> 
>   `clean'
>      Delete all files in the current directory that are normally
>      created by building the program.  Also delete files in other
>      directories if they are created by this makefile.  However, don't
>      delete the files that record the configuration.
                             ^^^^^^^^^^^^^^^^^^^^^^^^ = the Makefile and
other files created by ./configure. That's exactly the same to what I
cited.

>      Also preserve
>      files that could be made by building, but normally aren't because
>      the distribution comes with them. ...

This is a "can", not a "must" and this should IMHO be decided by the
developers of each software package and not by the gettext
developer(s). 

And IMO the above paragraph fits special files (e.g. manpages created
from XML source), that should be shipped with the source without forcing
the user to install packages, the software he wants to compile does not
really depend on (in this example e.g. libxml2). It does IMO not fit
your situation nor gettext as project.

> 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".)

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?

On the other hand, shipping these files with the _source_ archive just
increases the archive size, which is not user-friendly and just wastes
space and bandwith. Could you please at least add a macro to preserve
the "old" behaviour if you really think, there are many users that
install a gettext-depending package without having gettext.

> > Otherwise they will never be updated
> 
> The *.gmo files don't need to be updated often.

That may be the case. But when I update a .po-file, I expect, that the
resulting .gmo file is updated too. I do not expect, that I have to
manually walk through the tree and call make targets. Maybe some
maintainers complained about a logical sequence of build-steps for .gmo
files. I do not.

But even with your argument I expect, that .gmo files are at least
removed in distclean and not in maintainer-clean, that states:

"This command is intended for maintainers to use;"
"it deletes files that may require special tools to rebuild."

which fits all files that are created by autogen.sh or similar scripts
(that belong into a VCS and not a source distribution) than additional
tools like msgfmt or gcc or similar. Running 'make maintainer-clean'
just to remove .gmo files removes all build environment files too and
this would leave the user with a source archive he cannot use (he would
have to manually run all the autotools the source needs). I hope you
don't interpret "special tools" as "all tools except make and
configure". In this case everything has to be removed in
'maintainer-clean' and nothing in 'clean' or 'distclean'.

> Earlier the Makefile rules
> updated the *.gmo files each time the *.po files changed,
> and the *.po files each time the .pot file changed,
> and the .pot file each time the sources
> changed. The maintainers were annoyed by this - in their eyes - useless
> waste of CPU cycles.

I'm not annoyed by this. That's exactly what I expect. Any chance to
handle this via macro? The macro could add the 'make update-gmo' target
to the 'make (all)' target for people like me, that don't like to walk
through the source to manually run make targets or remove files manually
or be forced to remove the whole build environment just to update some
files.

@Santiago: I'm a little bit surprised, that you even didn't wait for my
answer before you closed the report.

Regards, Daniel





reply via email to

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