bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7773: (lack of) config.h description in manual


From: Eric Blake
Subject: bug#7773: (lack of) config.h description in manual
Date: Mon, 03 Jan 2011 17:33:42 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

[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,
> address@hidden 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,
address@hidden 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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]