I `should' (following the GNU-ish conventions) be able to configure
and build with, say, the default $prefix and then just `make install
prefix=...' to install under another name.  (This is generally
necessary if, for instance, /usr/local is a read-only mount point.)
The current build system goes to some lengths to defeat this for some
reason, unlike any other package I know.

Is there actually a good reason for that, or would you accept a patch
to give the normal autoconf behaviour?

On Thu, Nov 17, 2005 at 12:22:54PM +0000, Dave Love wrote:
> Is there actually a good reason for that, or would you accept a patch
> to give the normal autoconf behaviour?

I don't know of a good reason for this, although I'm not sure precisely
where the problem is, unless you're referring to the sysconfdir handling.
In that case, the idea is to be in line with LSB, and not placing the conf
files in /usr/etc (or /usr/local/etc).

The main issue is that we don't want to break packagers' scripts if we can
avoid that.
-- 
David Roundy
http://www.darcs.net

> I `should' (following the GNU-ish conventions) be able to configure
> and build with, say, the default $prefix and then just `make install
> prefix=...' to install under another name.

I believe that GNU makefiles do that by setting the DESTDIR variable.
This is fully supported by Darcs' build system.

                                        Juliusz

David Roundy <bugs@darcs.net> writes:

> I don't know of a good reason for this, although I'm not sure precisely
> where the problem is,

To be concrete, I expect to be able to build and install packages for
a /usr/local shared over many machines like this:

  .../configure && make && make install prefix=/dl/fcis/common/local

Here, /usr/local is automounted readonly, and /dl/fcis/common/local is
a writable version of it (exported to some machines).  Anything that
should be local gets copied by cfengine.  (This is obviously where for
some reason we can't use a package system, for `package' in the sense
of dpkg, rpm &c.)  It works fine for anything using automake and other
packages which use autoconf according to convention.

What you get now is this:

  # autoconf.mk.  Generated from autoconf.mk.in by configure.
  #
  bindir		:= /usr/local/bin
  sbindir		:= /usr/local/sbin
  mandir		:= /usr/local/man
  datadir		:= /usr/local/share
  sysconfdir	:= /etc
  libexecdir	:= /usr/local/libexec

What I'd expect is this, like in an automake-generated Makefile.in:

  # autoconf.mk.  Generated from autoconf.mk.in by configure.
  #
  prefix		:= /usr/local
  exec_prefix	:= ${prefix}
  bindir		:= ${exec_prefix}/bin
  sbindir		:= ${exec_prefix}/sbin
  mandir		:= ${prefix}/man
  datadir		:= ${prefix}/share
  sysconfdir	:= ${prefix}/etc
  libexecdir	:= ${exec_prefix}/libexec

> unless you're referring to the sysconfdir handling.
> In that case, the idea is to be in line with LSB, and not placing the conf
> files in /usr/etc (or /usr/local/etc).

I wasn't specifically referring to that, but I don't think it should
be changed from the autotools default, and `configure --help' says it
defaults to PREFIX/etc.

> The main issue is that we don't want to break packagers' scripts if we can
> avoid that.

The Debian package, for instance, has this an configuration rule:

  sh ./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --mandir=/usr/share/man

I'd expect other packaging arrangements to do similar where they're
building from source.  What might break?

Juliusz Chroboczek <bugs@darcs.net> writes:

> I believe that GNU makefiles do that by setting the DESTDIR variable.
> This is fully supported by Darcs' build system.

That's not the same thing.  I want to install in, say, $(prefix)/bin,
not $(DESTDIR)/usr/local/bin.  The latter is the only choice
currently, short of researching and specifying all ...dir variables
used by the makefile.

However, it should be, e.g. `$(DESTDIR)$(bindir)', not
`$(DESTDIR)/$(bindir)', though I don't know if the extra / would
actually lose in some circumstances.

On Thu, Nov 17, 2005 at 10:00:16PM +0000, Dave Love wrote:
> > The main issue is that we don't want to break packagers' scripts if we
> > can avoid that.
>
> The Debian package, for instance, has this an configuration rule:
>
>   sh ./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --mandir=/usr/share/man
>
> I'd expect other packaging arrangements to do similar where they're
> building from source.  What might break?

Ah, back in the days when I packaged darcs for debian, I don't think I did
that.  (Those smart debian maintainers!)

Okay, I think a patch to fix this sounds good, but probably not for 1.0.5,
which will most likely be issued pretty soon to fix some windows-related
bugs, since I'm still afraid there will be breakage.  It'll be Tommy's
call, of course, whether this goes into 1.0.5, but any sort of build script
change seems likely to me to break *someone's* system.
-- 
David Roundy
http://www.darcs.net

David Roundy <bugs@darcs.net> writes:

> Okay, I think a patch to fix this sounds good, but probably not for 1.0.5,

Sure.  It's not a huge problem, but it did take me a while to figure
out.

Here's a patch which makes it consistent with the normal conventions
and with what the configure help says.  It removes the superfluous
slash from DESTDIR too.

Attachments

• unnamed

Juliusz,

I think this patch should be applied.  It conflicts a little,
but I've made a resolution patch that fixes it.  Is it alright
with you if I apply it to darcs stable or, if you prefere,
(re)send the patch and conflict resolution to darcs-unstable?

> I think this patch should be applied.  It conflicts a little,
> but I've made a resolution patch that fixes it.  Is it alright
> with you if I apply it to darcs stable or, if you prefere,
> (re)send the patch and conflict resolution to darcs-unstable?

Either will do -- I always resynchronise with stable before applying
any patches.

                                        Juliusz

fixed in 1.0.6
Thu Nov 17 20:02:31 CET 2005  Dave Love <fx@gnu.org>
  * Obey normal autoconf conventions.