On Sunday 22 May 2011, Harald Sitter wrote: > On Tue, May 17, 2011 at 10:33 PM, Alexander Neundorf <[email protected]> wrote: > > On Sunday 15 May 2011, Alexander Neundorf wrote: > >> On Friday 11 March 2011, Harald Sitter wrote: > >> > On Thu, Mar 10, 2011 at 11:23 PM, Ben Cooksley <[email protected]> wrote: > >> > > Note that if I don't get a reply, I will be reverting commit > >> > > 1602df28e8b82aeeecb7cfb3fe1af52790be02d3 to Phonon in 24 hours in > >> > > order to restore my ability to build Phonon. > >> > > >> > We are working on a revert, just too much a hassle it is.. > >> > >> Only slightly related... > >> > >> there is the branch with improved cmake stuff from Patrick. > >> Do you mind if I have a look at what he did and add this one by one to > >> master ? > >> I.e. I would start with installing a PhononConfig.cmake when Phonon is > >> installed, and then go through the plugins one by one and make them find > >> that one properly. > >> > >> I just tried to build the plugins and failed, some, e.g. WaveOut and MMF > >> have a FindPhonon.cmake, but don't set CMAKE_MODULE_PATH, so it is not > >> found at all. > > MMF and WaveOut are not supported by *us*, so I am not at all > surprised they do not build :S > > >> What is the idea with the PHONON_BUILDSYSTEM_DIR variable ? > > > > Ok, found it. > > > > I'd suggest: > > *always* make LIB_INSTALL_DIR, INCLUDE_INSTALL_DIR and > > SHARE_INSTALL_PREFIX relative to CMAKE_INSTALL_PREFIX, i.e. not > > configurable via the cache anymore. > > > > Advantage: easier handling, and especially under Windows the package can > > be installed easily to arbitrary locations. > > > > This would mean that if CMAKE_INSTALL_PREFIX is e.g. /opt/phonon, the > > headers would always bee in /opt/phonon/include, the libs in > > /opt/phonon/lib[64], share in /opt/phonon/share. (currently you can > > configure these three locations to completely independent locations, > > which I think is not necessary for a library like phonon). > > Agreed.
Ok :-) > > I would suggest to install the buildsystem files not into share/phonon- > > buildsystem/, but into share/phonon/buildsystem/. > > Then also this generated library thingy file which is currently installed > > directly to CMAKE_INSTALL_PREFIX (I think you don't really mean that) > > could go e.g. into share/phonon/. Or maybe lib/phonon/. > > What generated library thingy? >From the bottom of the toplevel phonon CMakeLists.txt: # This generates a nice library descriptor to use with [1]. It also spits out # a script that makes installing various versions for an ABI check a lot easier. # Basically the script ends up in your build dir and by running it you will # get phonon installed to MAIN_SOURCE_DIR/../abi/VERSION/prefix. # You can then invoke the ABI check with something like: # abi-compliance-checker.pl -l phonon -d1 4.4.4/usr/4.4.4.xml -d2 4.4.57/usr/4.4.57.xml # [1] http://ispras.linux-foundation.org/index.php/ABI_compliance_checker > Changing the buildsystem path is fine by me. Though share/phonon would > be the obvious choice there, as Ubuntu for example dislikes having > sharable stuff (i.e. architecture independent files) in lib/ This is correct, but at least it's better than the other way round. > > There will be a PhononConfig.cmake file, which will be found by > > find_package(), and it will contain all the information about the > > installed phonon, like e.g. the include dir. > > It will be placed in lib/cmake/phonon/. > > Alternatively it could also go into lib/phonon/cmake/. > > lib/cmake/phonon sounds best (to have everything in a central place :)). Ok. Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
