Status of CMake Updates

[Nick Appleton]

Hi,

I’ve made changes in the CMake support merge-request in response to a few of the comments that have been made. I’m keen to see the changes rolled into the upcoming release if we can get it through the review. What is the actual process for someone to 'approve’ this work before I merge it?

Nick

[Ross Bencina]

Hi Nick,

Usually we would look for sign-off from at least one person with (a)
knowledge of the area and (b) who has been involved with the project for
a while.

In this case I would like to hear from Robert about whether it is OK to
merge. (@Robert, what do you think?)

Anyone who uses CMake should take a look now and voice any
concerns/comments/suggestions either here on the merge request comment
stream.

As an outsider to CMake, my reading of the situation is that so long as
the behavior on Windows is not disturbed, and no one has major
complaints, then we should merge it for the release. We should also
include some kind of message in the change log to the effect that this
is a contributed build script for the convenience for CMake users and
that ./configure and the MSVC project files remain our primary supported
build systems.

Thanks,

Ross.

Post by Nick Appleton
Hi,
I’ve made changes in the CMake support merge-request in response to a
few of the comments that have been made. I’m keen to see the changes
rolled into the upcoming release if we can get it through the review.
What is the actual process for someone to 'approve’ this work before
I merge it?
Nick

[Nick Appleton]

Hi Ross,

Post by Ross Bencina
Hi Nick,
Usually we would look for sign-off from at least one person with (a) knowledge of the area and (b) who has been involved with the project for a while.
Anyone who uses CMake should take a look now and voice any concerns/comments/suggestions either here on the merge request comment stream.
As an outsider to CMake, my reading of the situation is that so long as the behavior on Windows is not disturbed, and no one has major complaints, then we should merge it for the release. We should also include some kind of message in the change log to the effect that this is a contributed build script for the convenience for CMake users and that ./configure and the MSVC project files remain our primary supported build systems.

That sounds fine. I’ll wait for Robert to chime in with some comments. In the mean time, I will try to find some time to update the CMake documentation which I just stumbled upon in the Doxygen pages.

Nick

[Roland Winklmeier]

Hey there,

Post by Ross Bencina
Anyone who uses CMake should take a look now and voice any
concerns/comments/suggestions either here on the merge request comment
stream.

One question regarding the new CMake feature set: Does it include also
MinGW builds and if not may I ask to consider adding it? It is not easy to
build with MinGW since you can't use the MSVC project files and the current
cmake files didn't support it. Instead I had to build it with the normal
autobuild tools via msys which isn't easy after all. CMake would be a big
improvement on this.

Cheers Roland

[Nick Appleton]

Hi Roland,

Post by Roland Winklmeier
Hey there,
Anyone who uses CMake should take a look now and voice any concerns/comments/suggestions either here on the merge request comment stream.
One question regarding the new CMake feature set: Does it include also MinGW builds and if not may I ask to consider adding it? It is not easy to build with MinGW since you can't use the MSVC project files and the current cmake files didn't support it. Instead I had to build it with the normal autobuild tools via msys which isn't easy after all. CMake would be a big improvement on this.

I spent a little bit of time a couple of nights ago getting this working.

On my Windows machine I was able to use CMake to generate "MinGW Makefiles” and managed to get everything building and running through a normal Windows command prompt using mingw32-make except for the WASAPI hostapi. Feel free to try it out and provide comments: if you clone the PortAudio repository and checkout the “cmake_updates" branch, you will have access to everything that has been done so far.

Cheers,

Nick

[Roland Winklmeier]

Post by Nick Appleton
Hi Roland,

On 16 Sep 2016, at 10:13 PM, Roland Winklmeier <
Hey there,
Anyone who uses CMake should take a look now and voice any

concerns/comments/suggestions either here on the merge request comment
stream.

One question regarding the new CMake feature set: Does it include also

MinGW builds and if not may I ask to consider adding it? It is not easy to
build with MinGW since you can't use the MSVC project files and the current
cmake files didn't support it. Instead I had to build it with the normal
autobuild tools via msys which isn't easy after all. CMake would be a big
improvement on this.
I spent a little bit of time a couple of nights ago getting this working.
On my Windows machine I was able to use CMake to generate "MinGW
Makefiles” and managed to get everything building and running through a
normal Windows command prompt using mingw32-make except for the WASAPI
hostapi. Feel free to try it out and provide comments: if you clone the
PortAudio repository and checkout the “cmake_updates" branch, you will have
access to everything that has been done so far.

Hi Nick,

sorry for not coming back to you earlier. I was trying a build with
Mingw-w64 today and got two different build issues. I was running the
normal cmake, make build with default arguments:

cd build && cmake -G "MinGW Makesfile" ..
mingw32-make

The errors are:
* Many redefinition errors - see attached build.log. I was able to
workaround this by applying the patch from
https://github.com/mxe/mxe/issues/716
* After that, linking fails due to undefined references. Adding
SET(PA_LIBRARY_DEPENDENCIES ${PA_LIBRARY_DEPENDENCIES} winmm) helped.

Both fixes are in the attached patch if someone wants to look at and apply
it.
I haven't done any runtime testing, but purely compile testing.

Cheers Roland

[Ross Bencina]

Post by Roland Winklmeier
cd build && cmake -G "MinGW Makesfile" ..
mingw32-make
* Many redefinition errors - see attached build.log. I was able to
workaround this by applying the patch from
https://github.com/mxe/mxe/issues/716
* After that, linking fails due to undefined references. Adding
SET(PA_LIBRARY_DEPENDENCIES ${PA_LIBRARY_DEPENDENCIES} winmm) helped.
Both fixes are in the attached patch if someone wants to look at and
apply it.
I haven't done any runtime testing, but purely compile testing.

Hi Roland,

Nick's cmake patch is now in master. If you haven't already, would you
mind testing that your patch still works there please?

The wdm/ks change also showed up in a patch from Jitsi. I'm wondering
whether to wrap the removal in #ifndef __GNUC__ or to just remove it
outright. Any thoughts on whether removing it would be compatible with
original (non-w64) mingw? With winioctl.h removed it compiles OK in MSVC
2015.

Out of interest, which host APIs are you targeting?

Thanks,

Ross.


--- a/src/hostapi/wdmks/pa_win_wdmks.c
+++ b/src/hostapi/wdmks/pa_win_wdmks.c
@@ -94,7 +94,6 @@ of a device for the duration of active stream using
those devices
#endif

#include <windows.h>
-#include <winioctl.h>
#include <process.h>

#include <math.h>

[n***@appletonaudio.com]

Post by Ross Bencina

Post by Roland Winklmeier
cd build && cmake -G "MinGW Makesfile" ..
mingw32-make
* Many redefinition errors - see attached build.log. I was able to
workaround this by applying the patch from
https://github.com/mxe/mxe/issues/716
* After that, linking fails due to undefined references. Adding
SET(PA_LIBRARY_DEPENDENCIES ${PA_LIBRARY_DEPENDENCIES} winmm) helped.
Both fixes are in the attached patch if someone wants to look at and
apply it.
I haven't done any runtime testing, but purely compile testing.

Hi Roland,

Thanks for picking up on this. This was indeed an oversight on my part -
my testing with MinGW was minimal (as it did not work with the CMake
support originally anyway).

Post by Ross Bencina
The wdm/ks change also showed up in a patch from Jitsi. I'm wondering
whether to wrap the removal in #ifndef __GNUC__ or to just remove it
outright. Any thoughts on whether removing it would be compatible with
original (non-w64) mingw? With winioctl.h removed it compiles OK in
MSVC 2015.
Out of interest, which host APIs are you targeting?

Hi Ross,

I'm happy to set up a merge-request with Roland's CMake fixes in it -
but it will unlikely happen until the weekend.

I should probably do a little bit of additional testing with the CMake
builds under MinGW to see if I can get individual backends working in
isolation - the reason this all worked for me originally is that the
CMake ASIO hostapi does ask to link with winmm which masks winmm not
being included for the other hostapis.

If you have an opinion on the winioctl.h issue, let me know how or if
you'd like me to address it.

Nick