GNU bug report logs - #7773
(lack of) config.h description in manual

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7773 in the body.
You can then email your comments to 7773 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: karl <at> freefriends.org (Karl Berry)
To: bug-automake <at> gnu.org
Subject: Re: (lack of) config.h description in manual
Date: Mon, 3 Jan 2011 00:17:00 GMT

Following up to my own mail, it seems I have been missing something
basic all these years, since it's never come up in my own packages: in
order to use the directory variables like $(LIBDIR) in the code, it
seems each package has to hack them in to config.h, e.g., via gnulib's
"configmake" module.  Right?

This is surprising.  A programmer coming to the autotools would hardly
expect to have to write their own glue script merely to get access to
the standard directories in the code.

I strongly suggest explicitly discussing this in the manual.  Maybe even
showing an example of how to do it, or at least referring to gnulib's
configmake.

(It'd be even better IMHO to just make them standardly available in
config.h somehow, e.g., as #define AM_LIBDIR and the like, but I can't
wrap my mind around a real spec, sorry ...)

Thanks,
k

Message #10 received at 7773-done <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Karl Berry <karl <at> freefriends.org>
Cc: 7773-done <at> debbugs.gnu.org
Subject: Re: bug#7773: (lack of) config.h description in manual
Date: Mon, 3 Jan 2011 03:43:10 +0100

Hi Karl,

* Karl Berry wrote on Mon, Jan 03, 2011 at 01:17:00AM CET:
> Following up to my own mail,

No.  :-)  This opened a new bug report.  I'm closing it, for reasons
explained below.

> it seems I have been missing something
> basic all these years, since it's never come up in my own packages: in
> order to use the directory variables like $(LIBDIR) in the code, it
> seems each package has to hack them in to config.h, e.g., via gnulib's
> "configmake" module.  Right?

Well, the configmake module is an application of the technique described
in
  info Autoconf "Defining Directories"

> This is surprising.  A programmer coming to the autotools would hardly
> expect to have to write their own glue script merely to get access to
> the standard directories in the code.

All discussed in above node.

> I strongly suggest explicitly discussing this in the manual.  Maybe even
> showing an example of how to do it,

All done above.  No, I do not think that automake.info should repeat all
of autoconf.info information.

> or at least referring to gnulib's configmake.

Feel free to send a patch to autoconf-patches to amend that (or just
write there, and one of us will get to it).  Thanks.

> (It'd be even better IMHO to just make them standardly available in
> config.h somehow, e.g., as #define AM_LIBDIR and the like, but I can't
> wrap my mind around a real spec, sorry ...)

That does not work, and the above node explains why: the GNU Coding
Standards forbid it, implicitly.

Cheers,
Ralf

Message #13 received at 7773 <at> debbugs.gnu.org (full text, mbox):

From: karl <at> freefriends.org (Karl Berry)
To: Ralf.Wildenhues <at> gmx.de
Cc: 7773 <at> debbugs.gnu.org
Subject: Re: bug#7773: (lack of) config.h description in manual
Date: Tue, 4 Jan 2011 00:00:16 GMT

Hi Ralf,

    I'm closing it, for reasons explained below.

And I'm reopening it, maybe.  Not too clear on debbugs interactions.

    No, I do not think that automake.info should repeat all
    of autoconf.info information.

Me either.  I don't ever intend to suggest creating such redundancy.

      info Autoconf "Defining Directories"

Thanks for the reference.  Now that I know it, I suggest the Automake
manual simply have a sentence with an xref to that node.  Why?  Because
many people (e.g., almost all the new GNU maintainers) come to the
autotools through automake.  A pointer would help them (just as it would
have helped me, but anyway)

For example, as part of the amhello explanation:

--- ORIG/automake.texi	2011-01-02 00:24:40.000000000 -0800
+++ automake.texi	2011-01-03 15:57:50.000000000 -0800
@@ -1737,4 +1737,9 @@
 @file{README} during @code{make install}.
 
+One thing not covered in this example is accessing the installation
+directory values (@pxref{Standard Directory Variables}) from your
+program code, that is, getting them into @file{config.h}.  For this,
+@pxref{Defining Directories,,, autoconf, Autoconf}.
+
 
 @node Generalities

    That does not work, and the above node explains why: the GNU Coding
    Standards forbid it, implicitly.

Hmm, I'm not so sure that the GCS forbids doing the right thing (or that
it has to stay that way even if it does), but I won't pursue it further.
Life goes on.


Thanks,
k

Message #16 received at 7773 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: Ralf.Wildenhues <at> gmx.de, "bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	7773 <at> debbugs.gnu.org
Subject: Re: bug#7773: (lack of) config.h description in manual
Date: Mon, 03 Jan 2011 17:33:42 -0700

[Message part 1 (text/plain, inline)]

[adding bug-autoconf]

On 01/03/2011 05:00 PM, Karl Berry wrote:
> Thanks for the reference.  Now that I know it, I suggest the Automake
> manual simply have a sentence with an xref to that node.  Why?  Because
> many people (e.g., almost all the new GNU maintainers) come to the
> autotools through automake.  A pointer would help them (just as it would
> have helped me, but anyway)
> 
> For example, as part of the amhello explanation:
> 
> --- ORIG/automake.texi	2011-01-02 00:24:40.000000000 -0800
> +++ automake.texi	2011-01-03 15:57:50.000000000 -0800
> @@ -1737,4 +1737,9 @@
>  @file{README} during @code{make install}.
>  
> +One thing not covered in this example is accessing the installation
> +directory values (@pxref{Standard Directory Variables}) from your
> +program code, that is, getting them into @file{config.h}.  For this,
> +@pxref{Defining Directories,,, autoconf, Autoconf}.

The subtle point here is that installation directory values _cannot_
live in <config.h> (which is determined at configure time), but must
live somewhere determined at make time (either "configmake.h", or by
adding appropriate -Dabc=xyz arguments to CFLAGS).  So I agree with
adding a sentence, but it must be worded something like:

+One thing not covered in this example is accessing the installation
+directory values (@pxref{Standard Directory Variables}) from your
+program code, that is, converting them into defined macros.  For this,
+@pxref{Defining Directories,,, autoconf, Autoconf}.

I also agree that the autoconf manual should mention the gnulib
'configmake' module (it doesn't, yet).

> Hmm, I'm not so sure that the GCS forbids doing the right thing (or that
> it has to stay that way even if it does), but I won't pursue it further.

What the GCS requires is that you can do 'make prefix=/alternate/path'
and have that propagate through all the directory variables.  Anything
learned at configure time can thus be rewritten at make time, so the
only safe place to record a directory variable's value is at make time.
 I don't think this aspect of the GCS needs changing.

One other thing to point out is that the GCS documents that 'make
install' should ideally not rebuild any source code, but that this ideal
is only possible if you either _don't_ use 'make prefix=...', or if you
use the same prefix in both 'make prefix=...' and 'make install prefix=...'.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #19 received at 7773 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Eric Blake <eblake <at> redhat.com>
Cc: "bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>, 7773 <at> debbugs.gnu.org,
	Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#7773: (lack of) config.h description in manual
Date: Tue, 4 Jan 2011 08:13:33 +0100

Hello Karl, Eric,

* Eric Blake wrote on Tue, Jan 04, 2011 at 01:33:42AM CET:
> On 01/03/2011 05:00 PM, Karl Berry wrote:
> > Thanks for the reference.  Now that I know it, I suggest the Automake
> > manual simply have a sentence with an xref to that node.

Yes, I agree with that, and I am still going to do that.  You opened two
bug reports originally (inadvertently), I only closed the one that was
dealt with.  Sorry if that was unclear before.

> > Hmm, I'm not so sure that the GCS forbids doing the right thing (or that
> > it has to stay that way even if it does), but I won't pursue it further.
> 
> What the GCS requires is that you can do 'make prefix=/alternate/path'
> and have that propagate through all the directory variables.  Anything
> learned at configure time can thus be rewritten at make time, so the
> only safe place to record a directory variable's value is at make time.
>  I don't think this aspect of the GCS needs changing.
> 
> One other thing to point out is that the GCS documents that 'make
> install' should ideally not rebuild any source code, but that this ideal
> is only possible if you either _don't_ use 'make prefix=...', or if you
> use the same prefix in both 'make prefix=...' and 'make install prefix=...'.

I don't think that is correct.  In fact, I think it is entirely intended
to be possible to use a different prefix= setting for the all and for
the install targets, and the latter should still not rebuild sources.
Sort of a poor-man's DESTDIR.  You can see the usefulness on MSYS and
DJGPP (where DESTDIR does not work due to drive prefix concatenation).
(Of course Libtool doesn't support the non-DESTDIR way, but that's
another story ...)

Cheers,
Ralf

Message #22 received at 7773 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Eric Blake <eblake <at> redhat.com>, Karl Berry <karl <at> freefriends.org>,
	7773 <at> debbugs.gnu.org, "bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>
Subject: Re: bug#7773: (lack of) config.h description in manual
Date: Wed, 5 Jan 2011 01:53:44 +1100

I disagree that `make prefix=... install' is a poor man's DESTDIR.
Installing using DESTDIR will install things in
$(DESTDIR)/$(prefix)/bin (and so on), which is a right pain when it
comes to using something like GNU Stow to manage /usr/local.

-- Jack

On Tue, Jan 4, 2011 at 6:13 PM, Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> wrote:
> Hello Karl, Eric,
>
> * Eric Blake wrote on Tue, Jan 04, 2011 at 01:33:42AM CET:
>> On 01/03/2011 05:00 PM, Karl Berry wrote:
>> > Thanks for the reference.  Now that I know it, I suggest the Automake
>> > manual simply have a sentence with an xref to that node.
>
> Yes, I agree with that, and I am still going to do that.  You opened two
> bug reports originally (inadvertently), I only closed the one that was
> dealt with.  Sorry if that was unclear before.
>
>> > Hmm, I'm not so sure that the GCS forbids doing the right thing (or that
>> > it has to stay that way even if it does), but I won't pursue it further.
>>
>> What the GCS requires is that you can do 'make prefix=/alternate/path'
>> and have that propagate through all the directory variables.  Anything
>> learned at configure time can thus be rewritten at make time, so the
>> only safe place to record a directory variable's value is at make time.
>>  I don't think this aspect of the GCS needs changing.
>>
>> One other thing to point out is that the GCS documents that 'make
>> install' should ideally not rebuild any source code, but that this ideal
>> is only possible if you either _don't_ use 'make prefix=...', or if you
>> use the same prefix in both 'make prefix=...' and 'make install prefix=...'.
>
> I don't think that is correct.  In fact, I think it is entirely intended
> to be possible to use a different prefix= setting for the all and for
> the install targets, and the latter should still not rebuild sources.
> Sort of a poor-man's DESTDIR.  You can see the usefulness on MSYS and
> DJGPP (where DESTDIR does not work due to drive prefix concatenation).
> (Of course Libtool doesn't support the non-DESTDIR way, but that's
> another story ...)
>
> Cheers,
> Ralf
>
>
>
>

Message #25 received at 7773 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Jack Kelly <jack <at> jackkelly.name>
Cc: "bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>,
	Eric Blake <eblake <at> redhat.com>, 7773 <at> debbugs.gnu.org,
	Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#7773: (lack of) config.h description in manual
Date: Tue, 4 Jan 2011 22:26:45 +0100

Hello Jack,

* Jack Kelly wrote on Tue, Jan 04, 2011 at 03:53:44PM CET:
> I disagree that `make prefix=... install' is a poor man's DESTDIR.

OK ok, I didn't mean to offend anyone here.

> Installing using DESTDIR will install things in
> $(DESTDIR)/$(prefix)/bin (and so on), which is a right pain when it
> comes to using something like GNU Stow to manage /usr/local.

Sure.  Still, please don't top-post.

Thanks,
Ralf

Message #28 received at 7773 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Eric Blake <eblake <at> redhat.com>, automake-patches <at> gnu.org
Cc: "bug-autoconf <at> gnu.org" <bug-autoconf <at> gnu.org>, 7773 <at> debbugs.gnu.org,
	Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#7773: (lack of) config.h description in manual
Date: Sat, 8 Jan 2011 10:08:44 +0100

As part of addressing Automake bug#7766 and bug#7773, I'm pushing the
following in Karl's name, to the maint branch.

Cheers,
Ralf

2011-01-08  Karl Berry  <karl <at> freefriends.org>
	    Eric Blake  <eblake <at> redhat.com>

	docs: reference defining directories in amhello node.
	* doc/automake.texi (amhello Explained): Point to Autoconf
	manual for how to convert directory values into macros.
	(Optional): Fix grammar nit.

diff --git a/doc/automake.texi b/doc/automake.texi
index 43ad581..c63dbf3 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -1736,6 +1736,11 @@ amhello Explained
 The only important effect of this second line is therefore to install
 @file{README} during @code{make install}.
 
+One thing not covered in this example is accessing the installation
+directory values (@pxref{Standard Directory Variables}) from your
+program code, that is, converting them into defined macros.  For this,
+@pxref{Defining Directories,,, autoconf, The Autoconf Manual}.
+
 
 @node Generalities
 @chapter General ideas
@@ -2905,7 +2910,7 @@ Optional
 of Automake required the use of @code{AM_CONFIG_HEADER}
 (@pxref{Macros}); this is no longer the case.
 
-As for @code{AC_CONFIG_FILES} (@pxref{Requirements}), parts of the
+As with @code{AC_CONFIG_FILES} (@pxref{Requirements}), parts of the
 specification using shell variables will be ignored as far as
 cleaning, distributing, and rebuilding is concerned.
 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.