[Top][All Lists]
[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>
- Re: Mutilated stdlib.h, (continued)
- Re: Mutilated stdlib.h, Ralf Wildenhues, 2011/04/02
- Re: Mutilated stdlib.h, Bruno Haible, 2011/04/02
- Re: Mutilated stdlib.h, Ralf Wildenhues, 2011/04/03
- Re: Mutilated stdlib.h, Bruno Haible, 2011/04/03
- Re: Mutilated stdlib.h, Bruno Haible, 2011/04/05
- Re: Mutilated stdlib.h, Jim Meyering, 2011/04/06
Re: Mutilated stdlib.h,
Bruno Haible <=
- Re: Mutilated stdlib.h, Ralf Wildenhues, 2011/04/02
- Re: not breaking "make" after m4 macros and source files changed, Bruno Haible, 2011/04/02
- Re: not breaking "make" after m4 macros and source files changed, Stefano Lattarini, 2011/04/03
- Re: not breaking "make" after m4 macros and source files changed, Ralf Wildenhues, 2011/04/03
- Re: not breaking "make" after m4 macros and source files changed, Stefano Lattarini, 2011/04/03
- Re: not breaking "make" after m4 macros and source files changed, Bruno Haible, 2011/04/03
- [PATCH] {master} coverage: add tests on remake rules in more complex situations (was: Re: not breaking "make" after m4 macros and source files changed), Stefano Lattarini, 2011/04/06
Re: not breaking "make" after m4 macros and source files changed, Dave Hart, 2011/04/03
Re: Mutilated stdlib.h, Bruno Haible, 2011/04/02