bug-gnulib
[Top][All Lists]
Advanced

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

Re: Mutilated stdlib.h


From: Bruno Haible
Subject: Re: Mutilated stdlib.h
Date: Sat, 2 Apr 2011 02:00:56 +0200
User-agent: KMail/1.9.9

Hi Karl,

>>     Remember to always do a "make distclean" before running gnulib-tool or
>>     autoreconf. Otherwise such things can happen.

I write this for two reasons:

  - Personally I've come to use "make distclean" rather frequently,
    in particular after an update from gnulib, but also after updating
    a built package from the upstream version control after a month or two.
    Before I took this habit, I occasionally had compilation errors and
    bugs, like the one Bruce reported. So often, I discovered that I could
    have saved myself 15 minutes of bug hunting just by doing "make distclean;
    ./configure; make".

  - Additionally, when we get bugs reports like this on bug-gnulib, it leads
    to a lengthy support thread to ask "grep for INCLUDE_NEXT in your
    config.status", "look for the time stamps of Makefile and wchar.h".
    And the person asking for help cannot decide by himself which gnulib
    generated file is correct and which one is incorrect - because he does not
    know in detail how gnulib works.

> The autotools go to a lot of
> trouble to make it possible to rerun make and rebuild the 
> infrastructure without resorting to the big hammer of make *clean.
> This is very useful.  So gnulib breaks that now?

It's not gnulib that breaks it. It's that it's unreliable. The autotools
don't cope automatically with .m4 files that have been renamed, m4 macros
that have been renamed, conditional use of AC_CONFIG_LINKS when the
condition has changed, source .h files that have been renamed or removed,
and so on. Such situations are quite rare when someone works in an isolated
project, but become not so rare when people use gnulib.

Additionally, when it occurs in an isolated project, the developer knows
what were his most recent changes; this is not the case any more for the
average gnulib user when it comes to the recent changes in gnulib.

Since blindly rerunning "make" is unreliable, I find that people should
know that "make distclean; ./configure; make" is more reliable, since that
will save them time.

Bruno
-- 
In memoriam Karim Mohammedzadeh 
<http://en.wikipedia.org/wiki/Karim_Mohammedzadeh>



reply via email to

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