Bug#530597: dh isn't really helpful if the build dir isn't the top-level source dir
Fabian Greffrath
Version: 7.2.14
Severity: minor
Dear Joey,
the debhelper command sequencer "dh" isn't really helpful, if the
build directory (i.e. the directory containing the configure script
and Makefile) isn't the top-level source directory. As a prominent
example, I would like to package the XVID library, which has both the
configure script and the Makefile in a build/generic directory [1].
The most obvious debian/rules for this case would look like this:
#!/usr/bin/make -f
%:
cd build/generic && dh $@
but it fails instantly because debian/control cannot be read from this
directory. A possible solution would be symlinking the debian
directory from the top-level directory into build/generic before the
configure rule and remove this symlink in the clean rule, but this
soon becomes very ugly and hackish to make it actually work. For
example, the following debian/rules file works fine, but I have to
manually override every relevant rule with the same stupid and
redundant directory change (and thus I hate it):
#!/usr/bin/make -f
%:
dh $@
override_dh_auto_clean:
ln -sf ../../debian build/generic
cd build/generic && dh_auto_clean
rm -rf build/generic/debian
override_dh_auto_configure:
ln -sf ../../debian build/generic
cd build/generic && dh_auto_configure
override_dh_auto_build:
cd build/generic && dh_auto_build
override_dh_auto_install:
cd build/generic && dh_auto_install
Currently, I am managing this issue by patching a configure script and
a Makefile into the top-level source directory using this patch:
--- /dev/null
+++ xvidcore-1.2.1+debian/Makefile
@@ -0,0 +1,6 @@
+#!/usr/bin/make -f
+
+all:
+
+%:
+ -$(MAKE) -C build/generic $@
--- /dev/null
+++ xvidcore-1.2.1+debian/configure
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+cd build/generic && ./configure $@
and the following debian/rules file:
#!/usr/bin/make -f
%:
dh --with quilt $@
override_dh_auto_configure:
chmod +x configure
dh_auto_configure
However, I still don't feel comfortable with this hack. My propose is
to introduce another set of options to the "dh" command, namely
--configure-dir and --build-dir which can be used to point to the
directories containing the configure script and the Makefile and which
would default to "./" if unset. With these two commands, my
debian/rules file would finally look like this:
#!/usr/bin/make -f
%:
dh --configure-dir build/generic \
--build-dir build/generic $@
without the need for any further hacks.
I think it is important to keep --configure-dir and --build-dir
separate! Consider I would like to package the libmp4v2 library from
the mpeg4ip sources. I would have to run the configure script in the
top-level source directory and then dive down into the libmp4v2
directory to run the Makefile there.
What do you say?
Cheers,
Fabian
[1] Another less prominent example is the rott package, where the
Makefile is in the rott directory of the tarball.
--
Dipl.-Phys. Fabian Greffrath
Ruhr-Universitï¿œt Bochum
Lehrstuhl fï¿œr Energieanlagen und Energieprozesstechnik (LEAT)
Universitï¿œtsstr. 150, IB 3/134
D-44780 Bochum
Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail: gref...@leat.ruhr-uni-bochum.de
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Joey Hess
> My propose is to introduce another set of options to the "dh" command,
> namely --configure-dir and --build-dir which can be used to point to
> the directories containing the configure script and the Makefile and
> which would default to "./" if unset.
In the buildsystems branch in git, there is support for a
--builddirectory, but this is used in the more common case of specifying
a directory that the toplevel configure and make should be run from,
and which is deleted on clean.
I suppose you could get the behavior you want out of that if
dh_auto_clean could be prevented from removing the directory. However,
the case you describe certianly seems unusual; we expect to have a
toplevel Makefile, and it seems entirely appropriate for the packaging
to add one if upstream for whatever reason left it out. That to me
seems a better solution than adding more dh_auto_* switches for such an
unusual case.
BTW, Modestas, it looks like makefile.pm does not call mkdir_builddir to
create the builddir before using it?
--
see shy jo
Modestas Vainius
On 2009 m. May 26 d., Tuesday 21:28:57 you wrote:
> Fabian Greffrath wrote:
> > My propose is to introduce another set of options to the "dh" command,
> > namely --configure-dir and --build-dir which can be used to point to
> > the directories containing the configure script and the Makefile and
> > which would default to "./" if unset.
>
> In the buildsystems branch in git, there is support for a
> --builddirectory, but this is used in the more common case of specifying
> a directory that the toplevel configure and make should be run from,
> and which is deleted on clean.
>
> I suppose you could get the behavior you want out of that if
> dh_auto_clean could be prevented from removing the directory. However,
> the case you describe certianly seems unusual; we expect to have a
> toplevel Makefile, and it seems entirely appropriate for the packaging
> to add one if upstream for whatever reason left it out. That to me
> seems a better solution than adding more dh_auto_* switches for such an
> unusual case.
What the reporter is asking here is a way to tell dh where the source
directory is. He basically wants dh to chdir to that directory before
executing any build commands and to assume all files which are supposed to
live in the source directory can live somewhere else but the top level dir. I
think it is a reasonable request, it has a couple of use cases and could be
pretty easily implemented on top of current buildsystems branch and I'd be
willing to do that (probably for 7.3.1). So basically it is a wish for $ dh --
source-directory option.
Build directory is a bit different beast. The whole point of it is to support
building outside source tree, not inside it. If configure script is in the
build directory, it is effectively in-source building (at least from autoconf
POV), just now the source directory is somewhere else but top level dir as far
as dh is concerned.
However, I still have to finish docs for current stuff (I'm better at writing
code than docs, really) :D I'm really sorry for long delays, hopefully I'll
finish soon.
> BTW, Modestas, it looks like makefile.pm does not call mkdir_builddir to
> create the builddir before using it?
makefile.pm does not have "configure" support (on purpose) and it actually
depends on Makefile existance in the build directory. Its derivatives create
builddir at "configure" stage as needed (if needed). So Makefiles are supposed
to be created in the builddir while configuring or they already should exist
there for plain makefile.pm to be usable.
--
Modestas Vainius <mode...@vainius.eu>
Fabian Greffrath
> What the reporter is asking here is a way to tell dh where the source
> directory is. He basically wants dh to chdir to that directory before
> executing any build commands and to assume all files which are supposed to
> live in the source directory can live somewhere else but the top level dir.
That's right.
However, please do also consider the second use case that I mentioned:
To build and package the libmp4v2 library, you have to run the
configure script from the top-level directory of the MPEG4IP source
code and then run the Makefile in the lib/mp4v2 subdirectory.
This is what I understood as --configure-dir (./) and --build-dir
(./lib/mp4v2/). Sorry if I mixed these terms up altogether.
Cheers,
Fabian
Fabian Greffrath
Debian Bug Tracking System schrieb:
> - dh_auto_* --sourcedirectory can now be used to specify a source
> directory if sources and/or the whole buildsystem lives elsewhere
> than the top level directory. Closes: #530597
thank you very much for addressing this issue. However, I do not think
that my initial request is 100%-ly dealt with: debhelper is still not
able to handle the situation when the configure script and Makefile
are *not* in the same directory (i.e. --sourcedirectory).
Take for example the situation when I need to run './configure' from
the top level source directory and then run 'make -C libs/thislib'.
Currently this is only possible by overriding the dh_auto_build and
dh_auto_install rules to append the '-- -C libs/thislib' option.
However, I think this is a reasonable approach and don't consider
myself pedantic enough to reopen this bug report. ;)
Cheers,
Fabian
--
Dipl.-Phys. Fabian Greffrath
Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
Modestas Vainius
On 2009 m. July 2 d., Thursday 12:25:08 you wrote:
> Take for example the situation when I need to run './configure' from
> the top level source directory and then run 'make -C libs/thislib'.
> Currently this is only possible by overriding the dh_auto_build and
> dh_auto_install rules to append the '-- -C libs/thislib' option.
Or
override_dh_auto_configure:
dh_auto_configure --builddirectory=path/to/source
^^^^^^^^^^^^^^^^^^^^^
overriden to do in-source configure, --sourcedirectory is "inherited"
%:
dh --sourcedirectory=path/to/source --builddirectory=libs/thislib
^^^^^^^^^^^^^^^^^^^^^
default builddir
dh_auto is designed to build the whole package, you want to build a part of
it. So you will have to override, your case is special.
--
Modestas Vainius <mode...@vainius.eu>