[Build-common-hackers] Bug#410096: Please drop useless DEB_BUILDDIR_$(cdbs_curpkg) handling in DEB_CONFIGURE_INVOKE to permit reusal

Loïc Minier lool at dooz.org
Wed Feb 7 17:06:42 UTC 2007

Package: cdbs
Version: 0.4.48
Severity: wishlist
Tags: patch


 Could you please change in autotools-vars.mk:


 And in autotools.mk:


 The current DEB_CONFIGURE_INVOKE is complicated but its complexity is
 not useful/usable: $(cdbs_curpkg) is "config.status" in the scope of
 $(DEB_BUILDDIR)/config.status in autotools.mk and I expect it to be the
 same in any custom rule calling a ./configure to generate a
   I wanted to call $(DEB_CONFIGURE_INVOKE) from a debian/rules using
 the configure/$package extension mechanism, but I couldn't due to the
 current form of $(DEB_CONFIGURE_INVOKE).  Instead, I'm using:
        cd $(DEB_BUILDDIR_gtk2-engines-udeb) && \
                $(DEB_CONFIGURE_SCRIPT_ENV) \
                        $(DEB_CONFIGURE_SCRIPT) \
                                $(DEB_CONFIGURE_NORMAL_ARGS) \
                                $(cdbs_configure_flags) \
                                $(DEB_CONFIGURE_EXTRA_FLAGS) \

 Would you apply the proposed changes, I could use the slightly better:
  cd $(DEB_BUILDDIR_gtk2-engines-udeb) && \
        $(cdbs_configure_flags) \

 Alternatively, it might be possible to replace the current single
 configure call by a series of call, one per DEB_BUILDDIR_*, with a
 generic rule to build DEB_BUILDDIR_$package/config.status.

   Thanks for considering the proposed changes!

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

cdbs depends on no packages.

Versions of packages cdbs recommends:
ii  autotools-dev                 20060920.1 Update infrastructure for config.{
ii  debhelper                     5.0.42     helper programs for debian/rules

-- no debconf information

Loïc Minier <lool at dooz.org>

More information about the Build-common-hackers mailing list