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

[Yuë Liu]

On Sun, Mar 24, 2013 at 10:04 AM, Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
> 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).
osx.cmake is used when compile with the macports ports i made and
generate osx installer package, those ports lacks some dependencies so
i cannot build
PLUGIN_SPACENAVIGATOR
PLUGIN_VIDEOSHAPE
DOC
OKULARODPGENERATOR

pivot table feature has some compatibility issue with clang so i disabled
PLUGIN_STAGING

no braindump, karbon, plan because i heard they are unmaintained on
sprint, i'll reenable braindump later.

if one wants to build everything he can still use all.cmake on osx
only if he has all the calligra dependencies installed.

>
> 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