Product sets and platforms (e.g. OS X)

Friedrich W. H. Kossebau kossebau at kde.org
Sun Mar 24 14:04:09 GMT 2013


Hi Yue,

if I understand correctly you are using the osx.cmake as "all-that-builds-on-
osx" product set, right? When you asked me at the sprint about product sets, I 
did not have a clear mind about it. But meanwhile I get the opinion that 
product sets should be orthogonal to what can be build on a platform. As 
ideally all products should be buildable everywhere, and if not, they should 
be simply left out from the build (like happens now when a required external 
dependency is not found).

>From the diff between osx.cmake and desktop.cmake it seems that these have 
build problems right now on OS X:
BRAINDUMP
KARBON
PLAN
PLUGIN_SPACENAVIGATOR
PLUGIN_VIDEOSHAPE
PLUGIN_STAGING
DOC
OKULARODPGENERATOR

Ideally they would be disabled in the section
## Detect which products can be compile ##
in the toplevel CMakeLists.txt.

Then I would be interested what the real problems are. Did you just not look 
yet into packaging of these, or do they fail on building? Where did the 
find_package macros fail then, which should have catch any problems also on 
OSX?

Using a personal product set for controlling what gets build for packaging is 
perfectly fine. Myself I meanwhile have a small set of private product sets to 
switch between stuff I work on, only before committing I turn the big build 
(=all.cmake) on. But any platform related problems should be catched for all 
product sets, so not stored away in a single product set definition.

So can we turn the osx.cmake into rules in the toplevel CMakeLists.txt and 
perhaps a private product set definition for your packaging?
When I just committed the filter products I already left osx.cmake out, sorry. 
Actually I wanted to write this email and sort this issue before merging the 
filter products, but then forgot :/

Any other comments, thoughts?

Cheers
Friedrich



More information about the calligra-devel mailing list