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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
