Hello all! Lately I've been hell-bent to port several packages to MinGW. So far I have flac, kde-filesystem, libid3tag, libmad, libsamplerate, libsndfile, portaudio, portmidi, protobuf, and taglib built and running. (My goal is to make all of Mixxx's dependencies -- see http://www.mixxx.org/ for more information on this open-source DJing tool.) Mixxx is up and running on MS Windows when built with these dependent packages!
Now I'm trying to build phonon (so that I can enable some additional Mixxx features), and I ran into a problem -- its build is using the host's cmake configuration files! In phonon-4.6.0/phonon/CMakeLists.txt, after running "macro_optional_find_package(PulseAudio 0.9.15)", PULSEAUDIO_FOUND is TRUE, but none of the other variables are set, e.g. PULSEAUDIO_INCLUDE_DIR, PULSEAUDIO_LIBRARY, and PULSEAUDIO_MAINLOOP_LIBRARY. It shouldn't even be finding the host's cmake configuration during a cross-compile!
The problem seems to be in /usr/share/mingw/Toolchain-mingw{32,64}.cmake -- it looks like it needs a "SET(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)" line.
Also, it seems like there would have to be mingw{32,64}-cmake and mingw64-cmake packages, just to provide /usr/share/cmake/Modules -- executables wouldn't be necessary.
What do you think?
Steven Boswell
Steven Boswell II schreef op za 18-05-2013 om 17:55 [-0700]:
Now I'm trying to build phonon
About a year ago I tried to get various pieces of the KDE stack cross-compiled using the Fedora MinGW toolchain. The phonon package is also part of this. The spec file for it can be found at http://svn.nntpgrab.nl/svn/fedora_cross/mingw-phonon/mingw-phonon.spec
It currently contains some CMake-specific overrides. My original plan was to get all the core KDE packages built and afterwards trying to make the mingw32_cmake/mingw64_cmake macros in mingw-filesystem more generic. As I'm not that familiar with CMake and due to the lack of time I didn't get to completing this original plan.
If you want to continue with this work-in-progress, feel free to use the spec file I just mentioned as starting point. It can build phonon successfully.
On my svn repo you can also find other packages which are still a work-in-progress and need more work before they can be allowed in Fedora. If you're interested in maintaining any of them feel free to use them and propose them for review. The repo can be found at http://svn.nntpgrab.nl/svn/fedora_cross/
and I ran into a problem -- its build is using the host's cmake configuration files! In phonon-4.6.0/phonon/CMakeLists.txt, after running "macro_optional_find_package(PulseAudio 0.9.15)", PULSEAUDIO_FOUND is TRUE, but none of the other variables are set, e.g. PULSEAUDIO_INCLUDE_DIR, PULSEAUDIO_LIBRARY, and PULSEAUDIO_MAINLOOP_LIBRARY. It shouldn't even be finding the host's cmake configuration during a cross-compile!
I'm not familiar enough with CMake to tell you what's going on. Are you using the mingw_cmake (or mingw32_cmake/mingw64_cmake) macros to build the package?
The problem seems to be in /usr/share/mingw/Toolchain-mingw{32,64}.cmake -- it looks like it needs a "SET(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)" line.
This particular parameter is currently already set to 'NEVER' in the mingw-filesystem package. As mentioned before I'm not that familiar with CMake and I don't know what this parameter does. If you believe this parameter should be changed then I would recommend you to file a bugreport against mingw-filesystem with rationale why it should be changed.
Also, it seems like there would have to be mingw{32,64}-cmake and mingw64-cmake packages, just to provide /usr/share/cmake/Modules -- executables wouldn't be necessary.
Do you mean that you want to have a mingw-cmake package which only owns the folders %{mingw32_sysroot}/share/cmake/Modules and %{mingw64_sysroot}/share/cmake/Modules and doesn't have any other content? In that case I would be better to add this folder to the mingw-filesystem package.
Regards,
Erik van Pienbroek
Now I'm trying to build phonon
About a year ago I tried to get various pieces of the KDE stack cross-compiled using the Fedora MinGW toolchain. The phonon package is also part of this. The spec file for it can be found at http://svn.nntpgrab.nl/svn/fedora_cross/mingw-phonon/mingw-phonon.spec
Thanks for this resource. I tried desperately to find pre-existing work for all the MinGW packages I was trying to build, but didn't find your archive.
My original plan was to get all the core KDE packages built and afterwards trying to make the mingw32_cmake/mingw64_cmake macros in mingw-filesystem more generic. As I'm not that familiar with CMake and due to the lack of time I didn't get to completing this original plan.
If you want to continue with this work-in-progress, feel free to use the spec file I just mentioned as starting point.
I will! I'm pretty familiar with cmake, so I can help with this.
On my svn repo you can also find other packages which are still a work-in-progress and need more work before they can be allowed in Fedora. If you're interested in maintaining any of them feel free to use them and propose them for review. The repo can be found at http://svn.nntpgrab.nl/svn/fedora_cross/
Indeed I will! Real life is threatening to intrude any second now, but currently, I have time for this.
Are you using the mingw_cmake (or mingw32_cmake/mingw64_cmake) macros to build the package?
Yes, I am. I wouldn't try to do things the hard way :-)
The problem seems to be in /usr/share/mingw/Toolchain-mingw{32,64}.cmake -- it looks like it needs a "SET(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)" line.
This particular parameter is currently already set to 'NEVER' in the mingw-filesystem package. As mentioned before I'm not that familiar with CMake and I don't know what this parameter does. If you believe this parameter should be changed then I would recommend you to file a bugreport against mingw-filesystem with rationale why it should be changed.
Will do. If the reason behind this bug is lack of knowledge of cmake, that's fine -- that's where I'll be able to help. I have a few other things I'd like to fix too. I'll file a bug report about all of them at once.
Also, it seems like there would have to be mingw{32,64}-cmake and mingw64-cmake packages, just to provide /usr/share/cmake/Modules -- executables wouldn't be necessary.
Do you mean that you want to have a mingw-cmake package which only owns the folders %{mingw32_sysroot}/share/cmake/Modules and %{mingw64_sysroot}/share/cmake/Modules and doesn't have any other content? In that case I would be better to add this folder to the mingw-filesystem package.
Right now, my mingw32-cmake package contains the following:
/usr/i686-w64-mingw32/sys-root/mingw/etc/rpm/macros.cmake /usr/i686-w64-mingw32/sys-root/mingw/share/aclocal/cmake.m4 /usr/i686-w64-mingw32/sys-root/mingw/share/cmake/Modules/* /usr/i686-w64-mingw32/sys-root/mingw/share/cmake/Templates/* /usr/i686-w64-mingw32/sys-root/mingw/share/doc/cmake-2.8.10.2/Example/*
mingw64-cmake is similar.
If you'd rather put those into mingw-filesystem, that's your perogative. I'll go mess with the build of mingw-filesystem to see if I can figure out how to get them in there.
Steven Boswell
I wonder...would it be possible to put all these "not quite ready for prime time" MinGW packages into the testing repo? That certainly would have saved me a lot of time, and it would make them easily available, while at the same time making it clear that they might not work very well.
Steven Boswell
-
Erik van Pienbroek -
Steven Boswell II