Bruno Haible wrote:
>> Here's a proposed patch that uses the idiom presented in [1].
>
> Applied as well, due to absence of objections.
>
> 2011-04-05 Bruno Haible
>
> Remove leftover generated .h files after config.status changed.
>
> * m4/alloca.m4 (gl_FUNC_ALLOCA): New automake co
> Here's a proposed patch that uses the idiom presented in [1].
Applied as well, due to absence of objections.
2011-04-05 Bruno Haible
Remove leftover generated .h files after config.status changed.
* m4/alloca.m4 (gl_FUNC_ALLOCA): New automake conditional
GL_GENERAT
> > 2011-04-02 Bruno Haible
> >
> > Ensure to rebuild generated .h files when config.status has changed.
> > * modules/arpa_inet (Makefile.am): Add dependency from .h file to
> > config.status.
> > * modules/ctype (Makefile.am): Likewise.
> > ...
I've applied this now.
Bru
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
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
* 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
* 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,
* 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
Ralf Wildenhues wrote:
> if you have a rule to rebuild the
> header, but configure decides that your system is now good enough to
> cope without, the .Po files still record the dependency on the old
> replacement header, and that causes 'make' to invoke the rebuild rule.
>
> It seems to me that al
Ralf Wildenhues wrote:
> > - If gnulib-tool removes the generated files stdio.h, stdlib.h, and
> > similar,
> > the "make" process will rebuild a majority of the .o files and all
> > tests programs. Not much of a win, compared to running "make clean".
>
> I agree that removing them is n
Here's a valid test case:
$ ./gnulib-tool --create-testdir --dir=/tmp/testdir extensions
$ cd /tmp/testdir
$ gnulib-tool --source-base=gllib --m4-base=glm4 --add-import extensions
$ ./configure
$ make
$ gnulib-tool --source-base=gllib --m4-base=glm4 --add-import iswblank
$ make
$ gnulib-tool --sou
Hi Ralf,
I wrote:
> > make[2]: *** No rule to make target `../build-aux/c++defs.h', needed by
> > `c++defs.h'. Stop.
The command sequences were broken. With correct commands, I cannot reproduce
it. Sorry, false alarm again.
> That's what automake's dependency tracking code does
> (in the .Po a
Ralf Wildenhues wrote:
> --remove-import may not remove
> include_next.m4 (and others) because it is still used by wchar
> (directly or indirectly).
Indeed. "./gnulib-tool --create-testdir" is not made for subsequent
--add-import. The correct command sequence is
$ ./gnulib-tool --create-testdir -
* Bruno Haible wrote on Sat, Apr 02, 2011 at 02:00:56AM CEST:
> > 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 gnu
* Eric Blake wrote on Sat, Apr 02, 2011 at 12:42:07AM CEST:
> I've run into problems most frequently with two types of related
> changes: 1. gnulib changed the header.in.h template file for a
> replacement header, but because we (intentionally?) don't have a
> Makefile dependency, the header.h gene
* Bruno Haible wrote on Sat, Apr 02, 2011 at 01:37:27AM CEST:
> There's also a problem when the set of macros defined in .m4 files changes.
> Then 'autoconf' complains.
> $ ./gnulib-tool --create-testdir --dir=/tmp/testdir wchar
> $ cd /tmp/testdir
> $ configure
> $ make
> $ gnulib-tool --source-b
* Bruno Haible wrote on Sat, Apr 02, 2011 at 02:21:24AM CEST:
> - If gnulib-tool removes the generated files stdio.h, stdlib.h, and similar,
> the "make" process will rebuild a majority of the .o files and all
> tests programs. Not much of a win, compared to running "make clean".
I agree
Hello Bruno,
* Bruno Haible wrote on Sat, Apr 02, 2011 at 01:23:59AM CEST:
> There's also a problem when the set of files of a module changes:
> Dependencies to nonexistent files cause errors, like
>
> make[2]: *** No rule to make target `../build-aux/c++defs.h', needed by
> `c++defs.h'. Stop.
Eric Blake wrote:
> It would be really nice if gnulib-tool
> --update/--add-import/--remove-import could be taught to automatically
> remove all generated headers, which would solve the above problem and
> still allow incremental builds without needing an intervening 'make
> distclean'.
I'm agains
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 af
Eric Blake wrote:
> I've run into problems most frequently with two types of related
> changes:
There's also a problem when the set of macros defined in .m4 files changes.
Then 'autoconf' complains.
How to reproduce:
$ ./gnulib-tool --create-testdir --dir=/tmp/testdir wchar
$ cd /tmp/testdir
$ c
Eric Blake wrote:
> I've run into problems most frequently with two types of related
> changes:
There's also a problem when the set of files of a module changes:
Dependencies to nonexistent files cause errors, like
make[2]: *** No rule to make target `../build-aux/c++defs.h', needed by
`c++defs.
On 04/01/2011 04:22 PM, Karl Berry wrote:
> Remember to always do a "make distclean" before running gnulib-tool or
> autoreconf. Otherwise such things can happen.
>
> 1. I see nothing about this in the gnulib manual. Can the cases when
> "make distclean" is necessary be defined/narrowed a
Remember to always do a "make distclean" before running gnulib-tool or
autoreconf. Otherwise such things can happen.
1. I see nothing about this in the gnulib manual. Can the cases when
"make distclean" is necessary be defined/narrowed at all?
2. It is disheartening to read this. The
On 03/31/11 17:53, Bruno Haible wrote:
Bruce Korb wrote:
> rm -f stdlib.h-t stdlib.h&& \
> { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'&& \
Your Makefile is definitely not correctly generated.
It helps a lot to spell the configure macro correctly. :) Thanks.
Meanwhile, I
Hi Bruno,
On Thu, Mar 31, 2011 at 5:53 PM, Bruno Haible wrote:
> Bruce Korb wrote:
>> > rm -f stdlib.h-t stdlib.h && \
>> > { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && \
>> > sed -e 's|@''INCLUDE_NEXT''@||g' \
>> > -e 's|@''PRAGMA_SYSTEM_HEADER''@|@PRAGMA_SYSTEM_HEADER@|g'
Bruce Korb wrote:
> > rm -f stdlib.h-t stdlib.h && \
> > { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && \
> > sed -e 's|@''INCLUDE_NEXT''@||g' \
> > -e 's|@''PRAGMA_SYSTEM_HEADER''@|@PRAGMA_SYSTEM_HEADER@|g' \
> > -e 's|@''PRAGMA_COLUMNS''@|@PRAGMA_COLUMNS@|g' \
> >
27 matches
Mail list logo
