bug-autoconf
[Top][All Lists]
Advanced

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

Re: Bug#368502: autoconf: breaks existing build systems that use ${datad


From: Ben Pfaff
Subject: Re: Bug#368502: autoconf: breaks existing build systems that use ${datadir}
Date: Mon, 22 May 2006 16:34:18 -0700
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

Blake Barnett <address@hidden> writes:

> I work on the enlightenment project and this occurs when build any of  
> their packages.  A specific example of the problem is in the Embryo  
> library:
> http://e.kevb.net/cgi-bin/viewcvs.cgi/e17/libs/embryo/configure.in? 
> rev=1.37&content-type=text/vnd.viewcvs-markup

I tried to investigate by downloading and installing a snapshot
of "eet", which contains similar code in its configure.in and
which http://enlightenment.freedesktop.org/ says is a
prerequisite for embryo, or at least should be compiled first.
It compiled the same way with both the configure script that was
included and the one that I regenerated with Debian
2.59.cvs.2006.05.13-1.  The "make -n install" output was
identical from both.

The "configure" script from the CVS autoconf did report warnings
for the lack of datarootdir.  This appears to be harmless.  The
two versions of "configure" generated identical config.h, modulo
a few comments.  They also generated mostly identical
Makefile.in, except for a few worrisome parts that appear
unrelated to your bug report:

    -ac_ct_AR = ar
    +ac_ct_AR = @ac_ct_AR@

    +ac_ct_RANLIB = @ac_ct_RANLIB@
    +ac_ct_STRIP = @ac_ct_STRIP@

(Looks like some substitutions are missing somehow.  Perhaps I
need to run more than just "autoconf".)

So: can you be more specific about what the bug actually is?  As
far as I can tell, it configures, builds, and installs the same
way with both versions of Autoconf.  The CVS version does report
a warning from config.status; is the warning what you're
reporting as a bug?

I took a look at the configure.in itself in this package.  What
is it actually trying to do?  It is full of so much bizarre
cut-and-paste weirdness that I lose the thread of what's going
on.

Example:

    if test "x${bindir}" = 'x${exec_prefix}/bin'; then
      if test "x${exec_prefix}" = "xNONE"; then
        if test "x${prefix}" = "xNONE"; then
          bindir="${ac_default_prefix}/bin";
        else
          bindir="${prefix}/bin";
        fi
      else
        if test "x${prefix}" = "xNONE"; then
          bindir="${ac_default_prefix}/bin";
        else
          bindir="${prefix}/bin";
        fi
      fi
    fi

The two forks of the middle test (test "x${exec_prefix}" =
"xNONE") contain exactly the same code.  At least, I stared at
both of them for a long time and couldn't see any difference.
And then there's a similar block of code that does the same thing
for libdir.


-- 
"It was then I realized how dire my medical situation was.  Here I was,
 a network admin, unable to leave, and here was someone with a broken
 network.  And they didn't ask me to fix it.  They didn't even try to
 casually pry a hint out of me." --Ryan Tucker in the Monastery





reply via email to

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