bug-gnulib
[Top][All Lists]
Advanced

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

Re: maintainer-makefile troubles and suggestions


From: Martin von Gagern
Subject: Re: maintainer-makefile troubles and suggestions
Date: Thu, 21 Jan 2010 19:33:12 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20100119 Thunderbird/3.0

Hi Eric!

On 21.01.2010 17:10, Eric Blake wrote:
> Thanks for all the feedback!

I've got two more.

sc_prohibit_atoi_atof:
----------------------

The comment claims that [fs]?scanf doesn't provide error feedback. The
"return value" section of my scanf(3) man page says differently: the
number of successful conversions is returned, which is quite a suitable
error indication in many cases, I believe.

sc_prohibit_strcmp:
-------------------

Judging from the lib/streq.h file, STREQ seems to be only suitable for
comparison with fixed strings of lengths up to 9. Furthermore, its
invocation with both the string and the padded list of characters make
it quite bulky and hard to read. So I'd only suggest it in
performance-critical areas, never as a general rule.

Maybe you should have some kind of default test suite, so that people
can add such tests in corner cases but the default set is suitable for
most people and doesn't include such checks?

> 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:

Funy, you write "one" and comment on three... :-)

> That's already been patched in autoconf:

That's good to know. Thanks!

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

Can't get involved with that as well. gnulib is already more time right
now than I really can afford.

> You can exclude files specific to your project, using .x-* files.

I've been doing that, until I got fed up with those additional files
lying around and decided to put all that stuff in cfg.mk:
http://bzr.savannah.gnu.org/lh/wdiff/trunk/revision/66
It's a single line change, and likely easier applied manually than
automatically, at least after Jim applied the patches he just wrote
about. If you want me to, I can still send you a git patch, though.

> Also, many 
> projects tend to NOT version control generated files, like po/Makefile.in.in, 
> since they can be rebuilt during bootstrap.

Yes, and I would do so if I one of two conditions were met. If either I
could rely on distros to provide suitable gnulib packages, so that
autogen.sh could have a line for "gnulib-tool --update" and still be
expected to work on machines with basic package building software. Or if
I could rely on gnulib playing nice with gettext, so that I could have
gnulib in source and could still expect autopoint to perform its work.

As it is, I don't intend to drop gnulib code from the version controlled
tree, as there are (intentionally!) no releases, and as adding git or
cvs checkout code to autogen.sh feels evil. And if I have gnulib in tree
but not gettext, then autopoint (from gettext 0.17) will complain that
some files have been modified, and will refuse to install any
still-missing files. Plus I'd force all developers building from the
repository to have latest gettext installed, because gnulib only
supports latest gettext officially. Pretty ugly situation, I think.

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

In that case I'd suggest two targets, so you can call the suitable one
manually. You can always add fancy auto-selection one day when you have
a brilliant idea for it.

Greetings,
 Martin





reply via email to

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