Re: Mutilated stdlib.h

Hi Ralf, > > if GNULIB_GENERATED_BYTESWAP_H > > byteswap.h: byteswap.in.h > > ... > > else > > byteswap.h: > > rm -f $@ > > endif > > That looks interesting. I would want to test it and play around with it > before recommending it outright, though. You find a complete test case in the last

Re: not breaking "make" after m4 macros and source files changed

Hi Ralf, Stefano, > I'll make amend by writing the new testcases, if you can wait some more > time (maybe a couple of days). Thanks. You can take this as input (I have copyright assignment on file with Automake): > - A renamed m4 macro. > Before: m4/foo.m4 defines FOO1, configure.ac depend

Re: A bug in findutils?

On Mon, Mar 28, 2011 at 11:25 AM, Cao, Da-Shi (EB-Presales-ZTE/HW-GZ) wrote: > I've get the most recent version of gunlib by "git clone" and it seems that > the issue is resolved here. > How should I proceed with my findutils? There are 3 main options: 1. Wait for a new stable release (4.4.3 or

Re: not breaking "make" after m4 macros and source files changed

On Sun, Apr 3, 2011 at 08:22 UTC, Ralf Wildenhues wrote: > * Bruno Haible wrote on Sat, Apr 02, 2011 at 07:08:14PM CEST: >>   - A removed .h file. >>     Before: configure.ac depends on m4/macros.m4 that AC_SUBSTs STDIO_H to >> stdio.h. >>             lib/stdio.h is generated through lib/Makefile

Re: Interix list of mounted file systems.

On Thu, Jan 20, 2011 at 7:31 AM, Markus Duft wrote: > On 10/21/2010 12:35 PM, Jim Meyering wrote: >> Markus Duft wrote: >>> On 10/21/2010 11:59 AM, James Youngman wrote: On Thu, Oct 21, 2010 at 10:05 AM, Markus Duft wrote: > Hi! > > I just created the attached patch for findutils

Re: Mutilated stdlib.h

Hi Bruno, * Bruno Haible wrote on Sat, Apr 02, 2011 at 06:50:57PM CEST: > So, for example, you would propose to change modules/byteswap from [...] > But in that situation, when configuration decides that the system is > now good enough, the generated byteswap.h will stay on disk. "make" > will w

Re: not breaking "make" after m4 macros and source files changed

Hi Ralf, Bruno, and sorry for my previous sloppy(ish) answer. I'll make amend by writing the new testcases, if you can wait some more time (maybe a couple of days). On Sunday 03 April 2011, Ralf Wildenhues wrote: > Hi Bruno, > > * Bruno Haible wrote on Sat, Apr 02, 2011 at 07:08:14PM CEST: > > O

Re: Mutilated stdlib.h

* Bruno Haible wrote on Sat, Apr 02, 2011 at 06:30:05PM CEST: > "make distclean; ./configure; make" fixes the problem. But if you say that > the user should not need to do that, then we need a dependency > > string.h : $(top_builddir)/config.status > > What about this proposed patch, then? Looks

Re: Mutilated stdlib.h

* Bruno Haible wrote on Sat, Apr 02, 2011 at 06:42:46PM CEST: > Ralf Wildenhues wrote: > > Ideally, those rebuild rules > > work lazily for headers which are included often (i.e., if the contents > > don't change, the file isn't updated). > > For files that are rebuilt outside of Makefile rules,

Re: Mutilated stdlib.h

* Bruno Haible wrote on Sat, Apr 02, 2011 at 06:42:46PM CEST: > Ralf Wildenhues wrote: > > A nice and clean solution to would require a AC_CONFIG_FILES_LAZY macro > > or similar (similarly to how AC_CONFIG_HEADERS works, but it should also > > work if the second macro argument modified the output f

Re: not breaking "make" after m4 macros and source files changed

Hi Bruno, * Bruno Haible wrote on Sat, Apr 02, 2011 at 07:08:14PM CEST: > OK, let me get more constructive. For which of the following do you have > test cases in the Automake test suite already, that verify that after > "./configure" and "make" and some edits in the infrastructure, "make" > still

Re: Mutilating my own stdlib.h

Bruce Korb writes: > WRT "distclean", I never do that any more. > I clone the repo into a build directory and do all my > fiddling there. Yes, "git" has a command to remove > everything, but I developed my procedures back in > CVS (pre-svn) days, and old habits die hard > Purging all non-SCM

Re: not breaking "make" after m4 macros and source files changed

Hello Bruno, and thanks for bringing this up. On Saturday 02 April 2011, Bruno Haible wrote: > [CCing the automake list] > > Ralf Wildenhues wrote in > : > > > It's that it's unreliable. The autotools > > > don't cope automatical