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

[Jonas Smedegaard]

Hi Loïc,

On Wed, Feb 07, 2007 at 06:06:42PM +0100, Loïc Minier wrote:
> Could you please change in autotools-vars.mk:
>DEB_CONFIGURE_INVOKE = cd $(if $(DEB_BUILDDIR_$(cdbs_curpkg)),$(DEB_BUILDDIR_$(cdbs_curpkg)),$(DEB_BUILDDIR)) && $(DEB_CONFIGURE_SCRIPT_ENV) $(DEB_CONFIGURE_SCRIPT) $(DEB_CONFIGURE_NORMAL_ARGS)
>
> into:
>DEB_CONFIGURE_INVOKE = $(DEB_CONFIGURE_SCRIPT_ENV) $(DEB_CONFIGURE_SCRIPT) $(DEB_CONFIGURE_NORMAL_ARGS)
>
> And in autotools.mk:
>$(DEB_CONFIGURE_INVOKE) $(cdbs_configure_flags) $(DEB_CONFIGURE_EXTRA_FLAGS) $(DEB_CONFIGURE_USER_FLAGS)
>
> into:
>cd $(DEB_BUILDDIR) && $(DEB_CONFIGURE_INVOKE) $(cdbs_configure_flags) $(DEB_CONFIGURE_EXTRA_FLAGS) $(DEB_CONFIGURE_USER_FLAGS)
>
>
> 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 
> config.status.

You are right that $(cdbs_curpkg) expands to a bogus value in the 
default configure target, but if you construct targets like 
configure/pkgname:: then $(cdbs_curpkg) will resolve to pkgname.

Your proposed changes looks sensible, but will break routines for anyone 
currently overriding DEB_CONFIGURE_INVOKE.

We might be able to figure out a way to support your needs while not 
causing surprises for current users, but perhaps it is not needed, given 
my info above about cdbs_curpkg expansion.

Also, makefile and autotools snippets currently in cdbs Git supports 
expanding both DEB_BUILDDIR and DEB_DESTDIR with $(cdbs_curpkg).


> 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.

Actually, I could really use your help with this:

For more than a year I have used a local fork of the makefile and 
autotools snippets that support "flavors" - compiling the main code 
multiple times with different compile options.

I have now applied most of the improvements to mainline cdbs, but am 
hesitant if I should change something to the "flavor" handling: The way 
I have done it is by reusing the .../pkg construct as .../flavor.

Obviously that means one can _either_ use per-package builds _or_ 
flavored builds, but not both at the same time.

Imagine a source package containing multiple separate autotools 
environments, and one of them containing a Python library.  Would be 
cool to not need to repackage the upstream tarball, but just declare 
that each binary package should compile their own isolated builds, and 
that one of them additionally should build for all available Python 
versions.

Ideas?


The flavors-enabled snippets are used in multiple packages, including 
some that use it for Python building.  If you want to try figure out if 
it suits your need - and hopefully help make it support both flavors and 
per-package builds - then the most up-to-date snippets are in the libgd2 
Git at git://git.debian.org/git/collab-maint/libgd2


Kind regards, and sorry for the extremely late response,

  - Jonas

-- 
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20091106/be2cb549/attachment.pgp>