[Top][All Lists]

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

Re: maintainer-makefile troubles and suggestions

From: Eric Blake
Subject: Re: maintainer-makefile troubles and suggestions
Date: Thu, 21 Jan 2010 16:10:09 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Martin von Gagern <Martin.vGagern <at> gmx.net> writes:

> Here's a list of things that either caused me trouble or made me think.
> Some aspects of it involve parts of gnulib besides maint.mk.

Thanks for all the feedback!  I haven't looked closely at your fixes or at any 
of the points where you haven't yet provided patches, except for this one:

> sc_makefile_at_at_check:
> ------------------------
> That one contradicts the suggested practice from the current autoconf
> documentation with regard to autotest:
> http://www.gnu.org/software/autoconf/manual/html_node/Making-testsuite-

That's already been patched in autoconf:


> Personally I'd prefer it if automake could create all that boilerplace
> code automatically, or maybe you could include a makefile to do this, or
> use @variable@ substitution to provide it, or whatever. Until that
> happens, some clarification of this discrepancy would be nice.

Yes, it would be nice for automake to learn more about autotest.  I'm sure Ralf 
would welcome patches.  But it hasn't been enough of an itch for me (yet) to 
try writing such a patch.

> sc_makefile_TAB_only_indentation:
> sc_makefile_path_separator_check:
> ---------------------------------
> These complains about the po/Makefile.in.in installed by gettext 0.17.
> Perhaps you want to exclude that file, or file a bug against gettext? Or
> did someone already do so? It would be nice to know if these checks
> actually ensure portability, or simply improve legibility.

You can exclude files specific to your project, using .x-* files.  Also, many 
projects tend to NOT version control generated files, like po/Makefile.in.in, 
since they can be rebuilt during bootstrap.

> refresh-po:
> -----------
> Why do you use wget here, instead of rsync as suggested on the
> Translation Project info for package maintainers:
> http://translationproject.org/html/maintainers.html

If it were up to me, I'd like to see BOTH rsync and wget supported.  Why?  
Because half of my day, I'm stuck behind a firewall where wget can get through, 
but not rsync; but rsync does perform faster if there's not a firewall in the 
way.  The same goes for grabbing translation files in the gnulib bootstrap 
script.  But again, not something where I've had time to even think about 
patching it.

Eric Blake

reply via email to

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