After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 71678 - AUX_DIR guessing returns false result when package is inside a meta-package
AUX_DIR guessing returns false result when package is inside a meta-package
Status: RESOLVED INVALID
Product: intltool
Classification: Deprecated
Component: general
unspecified
Other other
: Normal normal
: ---
Assigned To: intltool maintainers
intltool maintainers
Depends on:
Blocks: 79332
 
 
Reported: 2002-02-16 16:07 UTC by ÉRDI Gergõ
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description ÉRDI Gergõ 2002-02-16 16:07:59 UTC 
If there's an autoconf meta-package that contains other autoconf packages
(like gtk-enterprise-edition), intltoolize will fail to recognize that
AC_CONFIG_AUX_DIR should default to '.', since when intltoolize is run for
the first time (from the sub-package's autogen script), if
AC_CONFIG_AUX_DIR is not explicitly defined in subpackage/configure.in, the
following code will be run:

  # Try to discover auxdir the same way it is discovered by configure.
  # Note that we default to the current directory.
  for dir in . .. ../..; do
    if test -f $dir/install-sh; then
      auxdir=$dir
      break
    elif test -f $dir/install.sh; then
      auxdir=$dir
      break
    fi
  done

however, 'install-sh' will not be found in the sub-package's root (since
intltoolize is run before install-sh is created), instead, the one in the
meta-package's root will be found, and thus, auxdir will be incorreclty set
to '..'.

For an example CVS module that is affected by this bug, look at gtkmm_hello
inside 'gnomemm' in cvs.gnome.org.
Comment 1 Darin Adler 2002-02-25 17:02:19 UTC 
Did you fix this already? I see a patch that seems to be about this.
Comment 2 ÉRDI Gergõ 2002-02-25 18:31:42 UTC 
No, I did check in a fix related to AUX_DIR handling but that has
nothing to do with this problem.
Comment 3 Kenneth Rohde Christiansen 2002-08-28 23:06:52 UTC 
What's up with this? Does the bug report still apply?
Comment 4 Murray Cumming 2002-08-29 08:12:28 UTC 
Yes, I just tried autogen-ing gnomemm/gtkmm-hello and got exactly the
same error.
Comment 5 Murray Cumming 2002-12-27 17:25:24 UTC 
This seems to cause make distcheck to succeed even when people have
mentioned the intl-* scripts in their Makefile.am files to distribute
them. This sounds like a big problem.
Comment 6 Kenneth Rohde Christiansen 2003-01-07 14:35:40 UTC 
Is this something you can look into Murray when you have time? I would
like this fixed, but I don't understand the bug well enought.
Comment 7 Murray Cumming 2003-01-07 15:43:48 UTC 
m4 isn't really my thing, and it isn't affecting me personally enough yet.

It's quite simple: intltools looks in the parent directory for
"install-sh", not just the current directory. This means that make
distcheck will suceed when it shouldn't.
Comment 8 Rodney Dawes 2004-11-04 20:25:41 UTC 
<murrayc> close it as old
<murrayc> I'll reopen it if we find it again.

Done and done.