RFC: Turning flag TINY into ACTIVEONLY, move Author to toplevel dir

[Friedrich W. H. Kossebau]

Am Dienstag, 19. Februar 2013, 23:21:23 schrieb Jaroslaw Staniek:
> On 19 February 2013 23:11, Friedrich W. H. Kossebau <kossebau at 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