Re: GNU packs with generated README
| An obvious, though not very elegant, solution would be to bootstrap like | this instead: | | -- | #!/bin/sh | | noreadme= | test -f README || noreadme=yes | test x$noreadme = x || touch README | set -x | aclocal | autoheader | automake -i --add-missing --copy | set +x | test x$noreadme = x || rm README Please, promote autoreconf use for bootstrapping. That way, we will be reported more cases, more bugs etc. which is always a good thing. In addition, in the future, if we add new people in the build system (such as the replacement of aclocal), although the actual chain of commands will have changed, the autoreconf call will remain constant.
Re: ac_config_libobj_dir broken
| > From: Akim Demaille <[EMAIL PROTECTED]>
| > Date: 06 Sep 2002 13:50:20 +0200
| >
| > > "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
| >
| > Andreas> The default value of ac_config_libobj_dir is wrong, it should
| > Andreas> be $srcdir. Similarily, AC_CONFIG_LIBOBJ_DIR should prepend
| > Andreas> $srcdir to the directory.
| >
| > Arg, you are right. But I'm not sure sticking srcdir in
| > ac_config_libobj_dir is the right thing to do. For instance, in the
| > replacement of fnmatch, you have:
| >
| > AC_CONFIG_LINKS([$ac_config_libobj_dir/fnmatch.h:$ac_config_libobj_dir/fnmatch_.h])
| >
| > This idiom is expected to spread, for getopt and others, and it should
| > not try to write in the $srcdir tree. I suppose there will be more
| > such examples where some replacement file will actually be in the
| > build hierarchy :(
| >
| > So I'm more inclined to paste $srcdir in from of $ac_config_libobj_dir
| > where needed.
| >
| > What do you (and other people :) think?
|
| Yes, I tend to agree. $ac_config_libobj_dir should be a relative
| path, and it should be a subdirectory of both $srcdir and of
| $builddir. It sounds like Autoconf should reject attempts to use an
| absolute directory as an argument to AC_CONFIG_LIBOBJ_DIR.
Here is my proposal. Once this checked in, shall we launch the
release process?
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* lib/autoconf/functions.m4 (AC_FUNC_GETLOADAVG): Use $srcdir when
looking for a replacement file.
* lib/autoconf/general.m4 (AC_CHECK_DECLS): Check that the
directory is relative.
* doc/autoconf.texi (Generic Functions): Clarify the replacement
directory definition.
Reported by Andreas Schwab and Jim Meyering.
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.667
diff -u -u -r1.667 autoconf.texi
--- doc/autoconf.texi 6 Sep 2002 11:10:37 - 1.667
+++ doc/autoconf.texi 9 Sep 2002 08:55:02 -
@@ -4109,11 +4109,15 @@
@defmac AC_CONFIG_LIBOBJ_DIR (@var{directory})
@acindex CONFIG_LIBOBJ_DIR
Specify that @code{AC_LIBOBJ} replacement files are to be found in
-@var{directory} (which defaults to @samp{.}, the top source directory).
-@command{configure} might need to know where these files are for the
+@var{directory}, a relative path starting from the top level of the
+source tree. The replacement directory defaults to @file{.}, the top
+level directory, and the most typical value is @file{lib}, corresponding
+to @samp{AC_CONFIG_LIBOBJ_DIR(lib)}.
+
+@command{configure} might need to know the replacement directory for the
following reasons: (i) some checks use the replacement files, (ii) some
macros bypass broken system headers by installing links to the
-replacement headers etc.
+replacement headers, etc.
@end defmac
@sp 1
Index: lib/autoconf/functions.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/functions.m4,v
retrieving revision 1.68
diff -u -u -r1.68 functions.m4
--- lib/autoconf/functions.m4 17 Jul 2002 16:55:49 - 1.68
+++ lib/autoconf/functions.m4 9 Sep 2002 08:55:03 -
@@ -553,8 +553,8 @@
[ac_have_func=no # yes means we've found a way to get the load average.
# Make sure getloadavg.c is where it belongs, at configure-time.
-test -f "$ac_config_libobj_dir/getloadavg.c" ||
- AC_MSG_ERROR([$ac_config_libobj_dir/getloadavg.c is missing])
+test -f "$srcdir/$ac_config_libobj_dir/getloadavg.c" ||
+ AC_MSG_ERROR([$srcdir/$ac_config_libobj_dir/getloadavg.c is missing])
ac_save_LIBS=$LIBS
@@ -600,7 +600,7 @@
AC_CACHE_CHECK(whether getloadavg requires setgid,
ac_cv_func_getloadavg_setgid,
[AC_EGREP_CPP([Yowza Am I SETGID yet],
-[#include "$ac_config_libobj_dir/getloadavg.c"
+[#include "$srcdir/$ac_config_libobj_dir/getloadavg.c"
#ifdef LDAV_PRIVILEGED
Yowza Am I SETGID yet
@%:@endif],
Index: lib/autoconf/general.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/general.m4,v
retrieving revision 1.802
diff -u -u -r1.802 general.m4
--- lib/autoconf/general.m4 31 Aug 2002 05:47:02 - 1.802
+++ lib/autoconf/general.m4 9 Sep 2002 08:55:04 -
@@ -2363,9 +2363,11 @@
# AC_CONFIG_LIBOBJ_DIR(DIRNAME)
# -
-# Announce LIBOBJ replacement files are in DIRNAME.
+# Announce LIBOBJ replacement files are in $top_srcdir/DIRNAME.
AC_DEFUN_ONCE([AC_CONFIG_LIBOBJ_DIR],
-[m4_divert_text([DEFAULTS], [ac_config_libobj_dir=$1])[]dnl
+[m4_bmatch([$1], [^]m4_defn([m4_cr_symbols2]),
+ [AC_WARNING([invalid replacement directory: $1])])dnl
+m4_divert_text([DEFAULTS], [ac_config_libobj_dir=$1])[]dnl
])
RE: GNU packs with generated README
In response to both Tim and Akim: >> An obvious, though not very elegant, solution would be to bootstrap >> like this instead: >> -- >> #!/bin/sh >> >> noreadme= >> test -f README || noreadme=yes >> test x$noreadme = x || touch README >> set -x >> aclocal >> autoheader >> automake -i --add-missing --copy >> set +x >> test x$noreadme = x || rm README This is more or less what I did to work around the problem (though I touched README in any case, and touched one of the sources of README as well, so README would be regenerated later) but as you say, it is not very elegant and hence, what I would like to avoid having to do. > Please, promote autoreconf use for bootstrapping. That way, we will > be reported more cases, more bugs etc. which is always a good thing. > In addition, in the future, if we add new people in the build system > (such as the replacement of aclocal), although the actual chain of > commands will have changed, the autoreconf call will remain constant. The problem with autoreconf is that I loose control over the reconf process, which gets me stuck with this problem and no way to work around it without calling autoreconf from a bootstrap script.. Ronald
Re: GNU packs with generated README
> "Ronald" == Ronald Landheer <[EMAIL PROTECTED]> writes: >> Please, promote autoreconf use for bootstrapping. That way, we >> will be reported more cases, more bugs etc. which is always a good >> thing. In addition, in the future, if we add new people in the >> build system (such as the replacement of aclocal), although the >> actual chain of commands will have changed, the autoreconf call >> will remain constant. Ronald> The problem with autoreconf is that I loose control over the Ronald> reconf process, which gets me stuck with this problem and no Ronald> way to work around it without calling autoreconf from a Ronald> bootstrap script.. Sorry, I don't understand what you mean :(
Re: ac_config_libobj_dir broken
| Index: ChangeLog | from Akim Demaille <[EMAIL PROTECTED]> | | * lib/autoconf/functions.m4 (AC_FUNC_GETLOADAVG): Use $srcdir when | looking for a replacement file. | * lib/autoconf/general.m4 (AC_CHECK_DECLS): Check that the | directory is relative. | * doc/autoconf.texi (Generic Functions): Clarify the replacement | directory definition. | Reported by Andreas Schwab and Jim Meyering. Committed.
Re: GNU packs with generated README
On Fri, Sep 06, 2002 at 01:37:57PM +0200, Ronald Landheer wrote:
> What I'd like to know is whether it is possible to keep the GNU (--gnu)
> standards for Automake's checking, but not have it look at README while
> bootstrapping [because README is a generated file, and doesn't exist
> yet at that point]
As a longer-term solution, perhaps some of those checks should be
done, not by Automake itself, but by the generated distcheck
target; specifically, checks for files like README that aren't
needed by the build.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
[...] despite reports to the contrary, it is the rare programmer who
permanently loses his sanity while coding ("permanently" being the
operative word).
- Eric E. Allen
Releasing Autoconf 2.54
If anybody sees a good reason to hold the release, please speak up now!
Difference between AM_CFLAGS, AM_CPPFLAGS, and AM_LDFLAGS
I am just posting this to make sure I understand the difference between these: AM_CFLAGS - compile time flags AM_CPPFLAGS - preprocessor flags (e.g. -I, -D) AM_LDFLAGS - linker flags (e.g. -L) I am working on a project that is updating its Makefile.am files. I see a variety of flags in one variable like CFLAGS contains -I and -F flags for example. I was wondering what is the advantage of doing this with automake variables? Stephen
Re: Difference between AM_CFLAGS, AM_CPPFLAGS, and AM_LDFLAGS
On Mon, 2002-09-09 at 23:11, Steve M. Robbins wrote: > On Mon, Sep 09, 2002 at 10:33:40PM -0500, Stephen Torri wrote: > > I am just posting this to make sure I understand the difference between > > these: > > > > AM_CFLAGS - compile time flags > > AM_CPPFLAGS - preprocessor flags (e.g. -I, -D) > > AM_LDFLAGS - linker flags (e.g. -L) > > Yes. > > > I am working on a project that is updating its Makefile.am files. I see > > a variety of flags in one variable like CFLAGS contains -I and -F flags > > for example. I was wondering what is the advantage of doing this with > > automake variables? > > Are you asking what is the advantage of separating them as automake > does? I guess the advantage is that automake uses, e.g. LDFLAGS for > linking lines where generic CFLAGS (-O, -g) might upset the linker. Yes. What is the advantage of separating them? Stephen
Re: Difference between AM_CFLAGS, AM_CPPFLAGS, and AM_LDFLAGS
%% Stephen Torri <[EMAIL PROTECTED]> writes: st> On Mon, 2002-09-09 at 23:11, Steve M. Robbins wrote: >> On Mon, Sep 09, 2002 at 10:33:40PM -0500, Stephen Torri wrote: >> > AM_CFLAGS - compile time flags >> > AM_CPPFLAGS - preprocessor flags (e.g. -I, -D) >> > AM_LDFLAGS - linker flags (e.g. -L) >> >> > I am working on a project that is updating its Makefile.am files. I see >> > a variety of flags in one variable like CFLAGS contains -I and -F flags >> > for example. I was wondering what is the advantage of doing this with >> > automake variables? >> >> Are you asking what is the advantage of separating them as automake >> does? I guess the advantage is that automake uses, e.g. LDFLAGS for >> linking lines where generic CFLAGS (-O, -g) might upset the linker. st> Yes. What is the advantage of separating them? Steve gave you the advantage: so you can run them individually. There are many compilers that won't accept linker flags (libraries, etc.) on a command line meant to compile a file (but not link it). The reason for having a separate CFLAGS and CPPFLAGS is even stronger: often you want to just run the C preprocessor (or a tool that takes the same arguments as the C preprocessor) either for debugging, or running tools like lint, or instrumenting your code with special debugging capabilities, etc. In this case you need to be able to run the preprocessor and be sure you're getting all the same arguments as when you compile the code into an object file. -- --- Paul D. Smith <[EMAIL PROTECTED]> HASMAT--HA Software Mthds & Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
