[Build-common-hackers] cbds & cmake (was Re: problems with multi-binary package)

IOhannes m zmoelnig zmoelnig at iem.at
Thu Aug 18 08:52:46 UTC 2011

Hash: SHA1

On 2011-08-17 22:18, Jonas Smedegaard wrote:
> No problem.  I came to same conclusion as you :-)
> NB! Your package lack build-dependency on som Boost libs.

thanks for having a look already...

i'm still trying to figure out some problems which i think are related
to the cmake.mk snippet

wishlist: when including cmake.mk, i really think this should add a
build-depend on "cmake".
i see a bug-report [1] on that and it seems the main obstacle for not
including the patch was, that it tried to automagically guess the cmake
version required. i personally think that automagic version discovery is
less important, and if required should be done manually (by defining
DEB_CMAKE_VERSION) or the like;
but including cmake.mk should at least add an unversioned b-d on cmake.

this of course is trivial to circumvent by adding a b-d on cmake
manually :-)

the real problem i have is, that the clean target does not seem properly
cmake.mk does all the build in a separate directory

which is nice.
unfortunately this builddir is not properly cleaned up when doing a
"make clean": all the cmake infrastructure will not be deleted!

otoh, when doing "make clean", code from buildcore.mk will try to run an
"rmdir $(DEB_BUILDDIR)" which eventually fails, since the directory is
not empty.

what's worse, is that the "cleanbuilddir" target (which tries to rmdir
the non-empty builddir) is run _before_ the "makefile-clean" target
(which is defined as a ::dependency of "cleanbuilddir" in makefile.mk)

a quick (and partial) overview on the "clean" dependencies and how they
get executed:

"clean" target depends on "testdir testroot cleanbuilddir reverse-config
"cleanbuilddir" rules are defined in buildcore.mk and makefile.mk
buildcore.mk:cleanbuilddir will rmdir the builddir
makefile.mk:cleanbuilddir depends on makefile-clean
makefile.mk:makefile-clean will run "make clean" in the builddir.

so it seems, what is going on is:
during an ordinary build, a builddir (that is different from the srcdir)
is created, populated and worked in, after that (with a populated
builddir) we do a "dpkg-buildpackage -Tclean":

- - "clean" depends on "cleanbuilddir"
- --1 "cleanbuilddir" calls "rmdir builddir"
   (this fails since the directory is still full)
- --  "cleanbuilddir" depends on "makefile-clean"
- ---2 "makefile-clean" calls "make -C builddir clean"
- ---  while this removes the binary objects from builddir, it still
leaves some cmake traces around

the "clean" target fails (and fails to properly clean as well)

i don't know enough make to understand why "makefile-clean" is called
after the first 'part' of "cleanbuilddir", even though it is a
'dependency' of "cleanbuilddir"
i thought it would be called first (it probably has to do the with order
of appearance...)

however, even if the "makefile-clean" would be called before the "rmdir
builddir" part, it would still fail, since builddir is not empty.

otoh, if "rmdir builddir" would actually succeed in removing the
builddir (e.g. by replacing it by "rm -rf builddir"), then
"makefile-clean" would fail, as it would try to issue a "make clean" in
a non-existant directory.

i think the way it should be is:
- - 1st call "makefile-clean"
- - 2nd call "cmake-clean" which empties the builddir from all cmake
leftovers (so that the builddir is empty afterwards)
- - 3rd call "rmdir builddir"

and until this is fixed in cdbs (if indeed cdbs is the culprit here),
how am i supposed to proceed with my package?


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501233
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20110818/9f5922ab/attachment.bin>

More information about the Build-common-hackers mailing list