On Mon, 2007-03-12 at 06:20 -0600, Richard Megginson wrote:
> Andrew Bartlett wrote:
> > Why is there a Makefile (not Makefile.in) in CVS?
> >
> Makefile is there for historical reasons and will be removed asap.
Great, thanks.
> > Isn't the first thing we want to do (on a checkout) a ./configure, which
> > will replace this file anyway?
> >
> > Likewise, I'm confused: why do we allow prefix and exec_prefix to be
> > specified at 'make' (rather than configure) time?
> You can set them at configure time. I use "configure
> --prefix=/home/rich/11srv && make install" for testing.
> > This is typically at
> > configure time in other open source projects.
> Actually, it is a "feature" of autoconf/automake to allow you to set
> them at make time, in addition to being able to set them at configure
> time. It is my understanding that autoconf/automake work fine, no
> matter if you set them at configure or make time. From "info autoconf":
> "Most of these variables have values that rely on `prefix' or
> `exec_prefix'. It is deliberate that the directory output variables
> keep them unexpanded: typically `@datadir@' will be replaced by
> `${prefix}/share', not `/usr/local/share'.
>
> This behavior is mandated by the GNU coding standards, so that when
> the user runs:
>
> `make'
> she can still specify a different prefix from the one specified to
> `configure', in which case, if needed, the package shall hard code
> dependencies corresponding to the make-specified prefix.
>
> `make install'
> she can specify a different installation location, in which case
> the package _must_ still depend on the location which was compiled
> in (i.e., never recompile when `make install' is run). This is an
> extremely important feature, as many people may decide to install
> all the files of a package grouped together, and then install
> links from the final locations to there.
> ...
> "
>
> There is more in the autoconf info doc about this too.
Yikes. That's very interesting. Can't blame GNU for lacking
features :-)
> > Changing this would seem
> > to remove some additional complexity from the build system...
> >
> What additional complexity is introduced?
It was this bit in Makefile.am that seems odd to me:
# these are for the config files and scripts that we need to generate
and replace
# the paths and other tokens with the real values set during
configure/make
# note that we cannot just use AC_OUTPUT to do this for us, since it
will do things like this:
# LD_LIBRARY_PATH = ${prefix}/lib/fedora-ds
# i.e. it literally copies in '${prefix}' rather than expanding it out -
we want this instead:
# LD_LIBRARY_PATH = /usr/lib/fedora-ds
if BUNDLE
fixupcmd = sed \
-e 's,@bindir\@,$(bindir),g' \
-e 's,@sbindir\@,$(sbindir),g' \
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
