On 2017-12-22 13:15 +0100, Christian Kandeler wrote: > On Fri, 22 Dec 2017 11:01:53 +0000 > Wookey <[email protected]> wrote: > > > One other thing that is an issue for debian: > > > > qbs clean doesn't actually clean out all its files; indeed it'll > > create one. It always leaves a $(PWD)/default/default.bg (or whatever > > build-dir name is in use). The debian build notices this new binary > > file added to the source tree and complains. A clean comand is > > supposed to clean out generated files, not generate more :-) > > > > Is there a way to stop this behaviour? > > If it really creates that file, then there was no build directory to begin > with (this is an error from 1.10 on, btw). The .bg file is the build graph > which contains all the meta data about the project, so it cannot be removed. > Compare to "make clean", which does not remove the Makefile either.
OK, but an autotools Makefile is shipped with the upstream tarball and thus debian package so leaving one around does not surprise dpkg-source. It does have an odd status in that it is ideally generated as part of the build (from Makefile.in, from Makefile.am), (by autoreconf) but is also shipped. This is due to autotools (frankly unhelpful) model of generating (some of) build file(s) on upstream release, not at build-time. Debian now tries to ignore this and encourages the running of autoreconf at build-time so that 'full' rebuild is done, not just a partial one. I agreee that the Cmake/Qbs model of doing all the build-file generation at build-time makes a lot more sense these days, and is more robust over the long term (e.g as new architectures get added). But it seems to me that it is correct that the build directory would not exist initially, and it would get created at build-time. So making that an error doesn't make much sense to me. Is your model that 'qbs clean' should never be run before 'qbs build' (which would create the directory)? That doesn't fit well with debian packaging, which always starts with the clean target (to try to ensure a clean build, especially when it is not out-of-tree). > I suppose we could add a "distclean" equivalent, e.g.: > $ qbs clean --wipe # simply removes the build dir That would work very well for debian packaging, I think. That's what I'm currently doing 'manually'. > > I am using this command: > > qbs clean --settings-dir /tmp profile:deb qbs-build > > which makes a qbs-build/qbs-build.bg > > ... if you haven't built the project before in that directory. Otherwise, the > file has already existed. > > > and also doesn't actually remove all the files in qbs-build. It > > removes the built binaries and the .o files but not the directories > > they were assembled in. > > If the directories are empty, they should be removed as well. If that does > not happen for you and you can reproduce the behavior with the current > release, please file a bug report. It's not easy for me to test the current release as it not in debian yet. But I'll try to do that. > > I have to do an 'rm -r qbs-build' anyway. Does the qbs clean command > > actually do anything else significant (e.g. in the settings dir) or > > should I just skip it and use 'rm -r qbs-build' ? > > For your purpose, rm is the right tool. qbs clean is more relevant to the > development cycle, where you want to keep the meta data (though it should > hardly ever be needed). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
signature.asc
Description: PGP signature
_______________________________________________ Qbs mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qbs
