That’s a very interesting article! However, I’ve noticed a strange thing.
The doc [0] says that CPPFLAGS variable is the "Options for the C preprocessor» which means this variable should map to cpp.cppFlags, not to cpp.commonCompilerFlags This also means that duplicated values passed as cpp.cFlags and cpp.cxxFlags could be passed once as cpp.commonCompilerFlags (with the assumption that Debian applications don't use ObjectiveC a lot) [0] https://manpages.debian.org/testing/dpkg-dev/dpkg-buildflags.1.en.html <https://manpages.debian.org/testing/dpkg-dev/dpkg-buildflags.1.en.html> Regarding profiles - strictly speaking, they are not mandatory, if gcc/clang can be found in PATH, one can build by simply invoking «qbs build qbs.toolchainType:gcc» / «qbs build qbs.toolchainType:clang» respectively (and passing all options on the command line). The first invocation is the same as «qbs build» on Linux since qbs.toolchainType is «gcc» on Linux by default. However, profiles might be an easier way to do a setup, your approach with «debian» profile is OK too - profiles are simply a «bag» of properties and are designed to avoid huge command line invocations Regarding clean rule - what if we add an extra option to qbs clean like «qbs clean --all» that will remove the *.bg file (build graph) as well? Will that be more convenient? > 29 февр. 2020 г., в 17:17, Wookey <woo...@wookware.org> написал(а): > > On 2020-02-29 09:05 +0300, Alberto Mardegan wrote: > > I have written a wiki page about using QBS to build debian packages: > https://wiki.debian.org/Qbs <https://wiki.debian.org/Qbs> > > I deal with QBS's desire to store a profile in the home directory by setting > --settings-dir to either /tmp (potential security risk as other can change > your build/config) or --settings-dir $(CURDIR)/debian for package builds.
_______________________________________________ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
