bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH 0/348] move AC_LIBOBJ invocations to the module descriptions


From: Jim Meyering
Subject: Re: [PATCH 0/348] move AC_LIBOBJ invocations to the module descriptions
Date: Mon, 13 Jun 2011 13:23:03 +0200

Bruno Haible wrote:
> In <http://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00174.html> we
> found out that every AC_LIBOBJ invocation must be triggered from a module
> that contains the referred file. Otherwise bugs occur.
>
> The most straightforward and safe way to ensure this is to more the AC_LIBOBJ
> invocations to the module descriptions. Additionally, this clarifies which
> files get compiled and under which conditions.
>
> Here is a series of proposed patches to gnulib that implement this for most
> *.m4 files. It consists of
>
>   - 260 changes of conditional AC_LIBOBJ invocations, and - where necessary -
>     an adjustment between the AC_LIBOBJ condition and the condition listed
>     in the 'Depends-on' section.
>
>     This series fixes 30 bugs (marked "Respect rules for use of AC_LIBOBJ" in
>     the respective ChangeLog entry).
>
>   - 88 changes of unconditional AC_LIBOBJ invocations. Here I had the choice
>     among just moving the AC_LIBOBJ to the configure.ac section and replacing
>     it with an augmentation of lib_SOURCES. I chose the second option
>     because it's more declarative and integrates better with Automake (allows
>     use of Automake conditionals).
>
>     This series fixes 2 bugs.
>
> Please review and comment. I'll wait for objections for a week.
>
> The patch is not complete:
>   - 20 files in *.m4 still to be done. These are the more complicated cases
>     (*printf, fchdir, sigpipe, nonblocking), which require more thought.
>   - There are more bugs regarding uses modules in "." and in "tests", which
>     will require modified idioms. By thinking through some of the bug
>     scenarios, I've convinced myself that this AC_LIBOBJ patch series will
>     help in developing these new idioms.
>
> But 32 fixed bugs is still an improvement.

That's an understatement ;-)
Thanks for all the work.  This looks like a fine improvement.
I reviewed only the first dozen or so.

This new policy looks particularly easy to violate accidentally.
What do you think about adding a syntax-check rule to help avoid that?



reply via email to

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