On Thursday 28 February 2013 Feb, Friedrich W. H. Kossebau wrote: > Hi, > > so macro_optional_add_subdirectory and the related cmake variables are > currently conflicting with that productset system I am working on. > > Looking at the old stuff I wonder how useful it is in such a big project, > like > Calligra now is. The BUILD_foo variables are generated from the foldername, > prepending "BUILD_". So this breaks once different products are done from > folders with the same name. Will happen e.g. with folders like "part", "app", > "view", "core". Also folder names will not be as expressive as the product > names need to be, like Jarosław mentioned in the original thread: > "BUILD_variables" would need "VARIABLES" as product name, not very expressive. > > So I would propose to drop any usage of macro_optional_add_subdirectory and > do > another system, based on the productset idea. > > But I wonder if anyone might be relying on what > macro_optional_add_subdirectory currently provides for Calligra. And thus > would need some backward compatibility for now. Does anyone know? > > Other comments regarding this wanted as well.
I think there are people activately using things like -DCREATIVEONLY=ON -DBUILD_KARBON=OFF, so for the apps having individual settings makes sense. I don't think anyone (but me, for certain windows builds) uses the ability to rm -rf a subdirectory and have macro_optional_add_subdirectory do the right thing. I also don't think there's anyone who does -DDISABLE_ALL_OPTIONAL_SUBDIRECTORIES=TRUE because that will break pretty much everything -- it would even disable the text shape. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel