Am Dienstag, 19. Februar 2013, 23:21:23 schrieb Jaroslaw Staniek: > On 19 February 2013 23:11, Friedrich W. H. Kossebau <kosse...@kde.org> wrote: > > Agreed. A perfect solution would allow the builder to define precisely > > which plugins/filters/modules/apps are to build (and then warn about all > > which cannot due to missings deps), and offer some prepared > > typical-pattern schemas for convenience. > > > > Perhaps a topic for the sprint? > > Yes. One thing to think about: BUILD_* variables generated by cmake > are based on the directory name what leads to often not > self-explanatory names. BUILD_words has clear meaning but > BUILD_variables is not if there are more than one 'variables' > directory in the whole calligra. This comes from the way how > macro_optional_add_subdirectory() behaves and could be improved by > adding a way to put extra context information. After that we be would > even able to invent some friendly configurator.
Ah, now I learnt the hard way what you meant with those BUILD_* variables :) So far I only knew that "macro_optional_add_subdirectory" can be used to cope with partial checkouts in svn times. That it adds the option to use additional cmake flags (-DDISABLE_ALL_OPTIONAL_SUBDIRECTORIES=TRUE, -DBUILD_foo=TRUE) is new to me. Hm. Partially possibly collides with the productset idea as I have implemented it for now. (Curious people can look themselves at that macro at https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/cmake/modules/MacroOptionalAddSubdirectory.cmake So need to think more about this, too late right now. Another thing that also needs more brain heat is products relying on hard dependencies that itselves have external hard dependencies. There should be a generic system which disables those products if the hard internal dependency cannot be build due to the external hard dependency missing. And I thought I was close to finish that primitive productset option with today's work on it (productset definitions in separate files)... bah. Hopefully the result can be even useful to other cmake-based projects which have lots of products in the same repo/buildsystem as well. Cheers Friedrich _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
