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