Conversion to the cmake building system. #3
Manually merged
SlavekB
merged 1 commits from feat/cmakeConv
into master
4 years ago
Loading…
Reference in new issue
There is no content yet.
Delete Branch 'feat/cmakeConv'
Deleting a branch is permanent. It CANNOT be undone. Continue?
A man page has been added.
Some differences with the Deb package:
Rem...koffice header...done!
kmplayerpartbase.cpp L141 hard-coded "cp" unix command...done!
Added patch to solve FTBFS in KOffice plugin and patch to complete cmake building of KOffice plugin.
WIP:Conversion to the cmake building system.to Conversion to the cmake building system. 4 years ago@SlavekB, please, give It a shot.
Your PRs are ok from my side.
Remember that there are additions in comparison to the Deb package (man page, koffice plugin, protocol and mime files).
@cethyel I was doing another test and I have some findings and questions:
I added include
CheckIncludeFileCXX
, because I probably forgot in – it's necessary for the koffice plugin test.I didn't find a reasonable reason why the GStreamer test should have two
WITH_...
options. You can look for example at Juk in tdemultimedia – there are tested three different versions with one condition. Therefore, I modified the test in kmplayer in a similar way.I looked at the mentioned protocol files. The problem is that such files are already contained in tdelibs. Here are some differences that would be good to unify. In the final, perhaps the only difference could be that in tdelibs files do not refer to any
exec
, while in kmplayer it refers to itself.I looked at the mentioned desktop files and this is a similar situation as with the protocol files == they are already contained in tdelibs and there seems to be no reason to be different. And so there's no reason to install them from kmplayer.
While dealing with the double option for
WITH_GSTREAMER
, I realized that manyWITH_...
options are probably wrong because they are redundant or directly conflicting with theBUILD_...
options.For example,
BUILD_KGSTPLAYER=ON
together withWITH_GSTREAMER=OFF
may causes FTBFS to occur. Conversely,WITH_GSTREAMER=ON
together withBUILD_KGSTPLAYER=OFF
makes theWITH_GSTREAMER
option unnecessary.Therefore, I propose to review the
WITH_...
options and decide which ones are not needed, becauseBUILD_...
will be the decisive option for the appropriate tests.@SlavekB
I have no ideas what the protocole desktop files play, so I included them in hope that you can shed some light upon.
The gstreamer1/0.10 test like in "juk" is nice addition.
Time has passed and I don't remember why I added the "with" and "build" options on the xine and gstreamer backend engines but It was either to mimic as much I could the configure options (since I don't want to deal with the autotools), or/and to make sure that kmplayer can be build with only one backend.
Anyhow I never expected a packager "dumb" to the level that he should pass a build option without the appropriate backend engine.
Regarding those options we may turn this the other away around since we already have the "HAVE_XINE" and "HAVE_GSTREAMER" definitions in the source code, meaning we keep the "with" options. This is speculation at this point since I can't test right now, I'll be back to you, on this, next week.
Greg, I did another test and comparison of CMake × Automake and I found that D-Bus and NSPR are required, but only because of KNPPlayer. Therefore, I removed the
WITH_NSPR
option and checks for D-Bus and NSPR I moved into the conditionBUILD_KNPPLAYER
.I test on Debian Bullseye and I get FTBFS during the CMake configuration:
I did a test on Wheezy and Stretch and everything's fine there. There seems to be a need for further efforts.
Changing from a complex
check_include_file_cxx
to a simplefind_path
resolved the KOffice detection problem.@cethyel good work, good cooperation, thank you!
1144a3b3e7
.