CMake support

[Nick Appleton]

Hello,

I’m working on expanding PortAudio’s CMake support to cover OS X and Linux (it will simplify the use of PortAudio in my own projects). I am just poking the mailing list to see if anyone has fiddled with this before and whether there is interest in this sort of thing being pushed back into the mainline once I have it working? I’ve noticed Robert Bielik’s name around the place in relation to the original Windows CMake support, is it still being maintained? I’ve been refactoring the CMakeLists.txt file locally to reduce some of the complexity and have just started to get things building on OS X. :) I’m also hoping to get “make; make install"-like functionality working with the CMake generated output if I can.

Nick

[Robert Bielik]

Hello Nick!

Post by Nick Appleton
I’m working on expanding PortAudio’s CMake support to cover OS X and
Linux (it will simplify the use of PortAudio in my own projects). I am just
poking the mailing list to see if anyone has fiddled with this before and
whether there is interest in this sort of thing being pushed back into the
mainline once I have it working? I’ve noticed Robert Bielik’s name around the
place in relation to the original Windows CMake support, is it still being
maintained? I’ve been refactoring the CMakeLists.txt file locally to reduce
some of the complexity and have just started to get things building on OS X.
:) I’m also hoping to get “make; make install"-like functionality working with
the CMake generated output if I can.

Yes, I did the original CMakeLists.txt file for Windows support, but at the moment I'm not using it so cannot really
say it is maintained.

But PA is an Open Source effort and all improvements are welcome! :)

When you do the refactoring, keep in mind that some users (like me f.i.) like to have the sources and build my entire
project via CMake (i.e. not using CMakes "FindPackage" option). Many libraries using CMake tend to forget this usecase.

All the best
/Robert Bielik

[Nick Appleton]

Hi Robert and Phil,

Post by Robert Bielik
Hello Nick!

Post by Nick Appleton
I’m working on expanding PortAudio’s CMake support to cover OS X and
Linux (it will simplify the use of PortAudio in my own projects). I am just
poking the mailing list to see if anyone has fiddled with this before and
whether there is interest in this sort of thing being pushed back into the
mainline once I have it working? I’ve noticed Robert Bielik’s name around the
place in relation to the original Windows CMake support, is it still being
maintained? I’ve been refactoring the CMakeLists.txt file locally to reduce
some of the complexity and have just started to get things building on OS X.
:) I’m also hoping to get “make; make install"-like functionality working with
the CMake generated output if I can.

Yes, I did the original CMakeLists.txt file for Windows support, but at the moment I'm not using it so cannot really
say it is maintained.
But PA is an Open Source effort and all improvements are welcome! :)
When you do the refactoring, keep in mind that some users (like me f.i.) like to have the sources and build my entire
project via CMake (i.e. not using CMakes "FindPackage" option). Many libraries using CMake tend to forget this use case.

You and I are both doing the same thing with building the entire project via CMake so I hopefully won’t break anything for you :) I do have one question: in cmake_support/options_cmake.h.in there is the following text:

Header file configured by CMake to convert CMake options/vars to macros. It is done this way because if set via
preprocessor options, MSVC f.i. has no way of knowing when an option (or var) changes as there is no dependency chain.

I’m trying to wrap my head around this comment and whether CMake’s behaviour has changed in recent years or something? On OS X in my prototype, if I turn on/off the CoreAudio support, CMake will ensure that the files which were influenced by the PA_USE_COREAUDIO macro will be rebuilt. This check should happen in Visual Studio projects as well (it’s the point of the whack ZERO_CHECK sub-project in all CMake generated VS solutions). Are we sure that the options_cmake.h file is actually required and that we cannot just set the appropriate macros? Or am I missing something here?

Post by Robert Bielik
Subject: Re: [Portaudio] CMake support
Date: 31 July 2016 at 7:00:40 AM AEST
I would love to see CMake support for other platforms. Would you make one giant CMakeLists.txt files or reference platform specific sub files?

At the moment, I plan to get everything into the one CMakeLists.txt file as nicely as possible (within reason - it is CMake). My main rationale for single-file is that while autoconf is the dominant build system, having CMakeLists scattered throughout the tree means that it is not always obvious where one needs to go to fix CMake if a change is made to the autoconf related stuff. Hopefully what I put together is easy for others to maintain. It’s not ideal long-term for my use-case (and Robert’s also by the sound of it) as whenever the Portaudio tree is included by another CMake project, both the static and dynamic libraries get built which is not normally what is desired. This could be blocked via more CMake options, but from my experience, the more options you insert into a CMake script, the crazier it ends up being to maintain it. There are other ways around this which involve putting CMakeLists in different locations which I think ends up working well, but if I go into detail it’ll end up turning into a rant - and a mailing list is no place for such things. :)

Ta,

Nick

[Robert Bielik]

Hi Nick,

I'm trying to wrap my head around this comment and whether CMake's behaviour has changed in recent years or something? On OS X in my prototype, if I turn on/off the CoreAudio support, CMake will ensure that the files which were influenced by the PA_USE_COREAUDIO macro will be rebuilt. This check should happen in Visual Studio projects as well (it's the point of the whack ZERO_CHECK sub-project in all CMake generated VS solutions). Are we sure that the options_cmake.h file is actually required and that we cannot just set the appropriate macros? Or am I missing something here?


I'm not sure what happens in VS today with f.i. a preprocessor setting changing from VAR=0 to VAR=1, the idea is that a rebuild of affected sources should be triggered. It certainly didn't with the VS version I had when I wrote the options_cmake stuff...

Regards
/Rob

[Robert Bielik]

That said, you are correct, it can be a CMake version issue also.

/Rob

From: portaudio-***@lists.columbia.edu [mailto:portaudio-***@lists.columbia.edu] On Behalf Of Robert Bielik
Sent: den 31 juli 2016 14:29
To: portaudio list <***@lists.columbia.edu>
Subject: Re: [Portaudio] CMake support

Hi Nick,

I'm trying to wrap my head around this comment and whether CMake's behaviour has changed in recent years or something? On OS X in my prototype, if I turn on/off the CoreAudio support, CMake will ensure that the files which were influenced by the PA_USE_COREAUDIO macro will be rebuilt. This check should happen in Visual Studio projects as well (it's the point of the whack ZERO_CHECK sub-project in all CMake generated VS solutions). Are we sure that the options_cmake.h file is actually required and that we cannot just set the appropriate macros? Or am I missing something here?


I'm not sure what happens in VS today with f.i. a preprocessor setting changing from VAR=0 to VAR=1, the idea is that a rebuild of affected sources should be triggered. It certainly didn't with the VS version I had when I wrote the options_cmake stuff...

Regards
/Rob

[jeff shanab]

I don't know if this is totally off base but I do not let Visual Studio
know about CMake. I turn off it's ability to detect and try to run cmake.
The flow is cmake->visualstudio->product not Visual studio->cmake->visual
studio with lots of confirm dialogs->product
I do not ever check in or allow editing of the sln.

A pre-processor directive is compile time change. There is no dependency
issue if you close->generate->reopen.
But you may want to add another configuration that has or has not set this
directive so you can switch between the builds quickly or in a build server.

Post by Robert Bielik
Hi Nick,
I’m trying to wrap my head around this comment and whether CMake’s
behaviour has changed in recent years or something? On OS X in my
prototype, if I turn on/off the CoreAudio support, CMake will ensure that
the files which were influenced by the PA_USE_COREAUDIO macro will be
rebuilt. This check should happen in Visual Studio projects as well (it’s
the point of the whack ZERO_CHECK sub-project in all CMake generated VS
solutions). Are we sure that the options_cmake.h file is actually required
and that we cannot just set the appropriate macros? Or am I missing
something here?
I’m not sure what happens in VS today with f.i. a preprocessor setting
changing from VAR=0 to VAR=1, the idea is that a rebuild of affected
sources should be triggered. It certainly didn’t with the VS version I had
when I wrote the options_cmake stuff...
Regards
/Rob
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio

[Nick Appleton]

Hi,

I mentioned a week or so ago that I've been doing some reworks of the PortAudio CMake support to get it working on OS X and Linux. I've had good success, but have not been able to set up a merge request through the Assembla hosting. I was also unable to push changes I made in a branch to the repository as described in the UsingTheGitRepository wiki page (I guess I need permissions). I setup an account (my username is "nicholas.l.appleton") - but do I have to pay to use Assembla? Their website seems to strongly suggest that I do.

I have been working in a separate repository in my personal github space as I needed a location to push-to and pull-from on a few platforms while I am prototyping and testing. The repo is here: https://github.com/nickappleton/portaudio-cmake-updates and the only file I have modified is the top-level CMakeLists.txt and I've added "cmake_support/FindJack.cmake" to find Jack on Linux. The changes I have made can be viewed in this repository.

The work is incomplete (in the sense of not every Linux hostapi is supported), but I don't expect the structure of the CMakeLists.txt file will change much anymore so hopefully patches after this will be easier to understand. The additions and restructure has reduced the size of the existing CMakeLists.txt.

What I've done:

* I've added support for building PortAudio on OS X (CoreAudio hostapi) and Linux (ALSA and Jack hostapis) and have tested this on OS X 10.11 and Ubuntu 16.04. These can be built the usual way (cmake {portaudio directory} && make), and can also be included by larger CMake projects (a project can "add_subdirectory(portaudio directory)" to have access to the static or dynamic libraries).

* I've restructured the CMakeLists.txt to not pollute global CMake variables (like CFLAGS or include directories) when it is not necessary; this really only has an impact when PortAudio is included in a larger CMake project and prevents libraries which depend on it getting all of the PA-specific compiler definitions etc...

* I've tried as much as possible to keep the existing Windows behavior identical to what it was previously and to not change the look and feel of the Visual Studio solutions. I've also preserved the existing generation of the "options_cmake.h" file - but have not adopted this pattern for the Linux and OS X builds. I have ensured that I can still build PortAudio with Visual Studio 2015 community edition with the ASIO SDK.

What I would like to investigate/do:

* I'd really like to see if I can get CMake to generate an OS X framework for PortAudio. I think this would be pretty cool.

* I want to be able to support "make install" on Linux and possibly OS X if I cannot get the above working.

* I probably should try and get the other Linux hostapis setup - I'm just not entirely sure how I will test them..

---

I hope the new structure is easy to follow and understand. Please let me know about the Assembla business. I am not willing to pay for an account (if that is required) - but if it is not, could someone can reach-out to me off the mailing list to let me know what I am doing wrong.

Cheers,

Nick

[Nick Appleton]

Just to follow-up on the previous email:

* It turns out that modern CMake (version > 3) is able to generate OS X frameworks for shared libraries. I’ve provided an option in the CMakeLists to support this if the host CMake version is capable of doing so. I still would like to do more testing on this.
* "make install" support turned out to be trivial to enable - so this is now included and I can install a portaudio shared library and header files into a Ubuntu or OS X system (or an arbitrary location using the CMAKE_INSTALL_PREFIX definition which is equivalent to “--prefix” with a configure script). I just need to get some pkg-config action happening in there, but I don’t expect that to be difficult at all.

I’ve been trying to use the PortAudio configure.in as a reference for what the CMakeLists.txt should do and I’ve got a small question: the configure script does an endianness check and adds a “-DPA_LITTLE_ENDIAN” or “-DPA_BIG_ENDIAN” to the CFLAGS. This has never existed in the CMakeLists.txt file - so I wondered how pa_converters was working with CMake builds on Windows. I then found pa_endianness.h which also sets these definitions. Is the purpose of passing the PA_XXX_ENDIAN arguments in CFLAGS purely to provide the endianness for the cases where pa_endianness.h cannot figure it out? I’ve added an endianness check to the CMakeLists.txt to replicate the behaviour of the configure.in script, but am not entirely convinced it’s a good thing.

Nick

Post by Nick Appleton
Hi,
I mentioned a week or so ago that I've been doing some reworks of the PortAudio CMake support to get it working on OS X and Linux. I've had good success, but have not been able to set up a merge request through the Assembla hosting. I was also unable to push changes I made in a branch to the repository as described in the UsingTheGitRepository wiki page (I guess I need permissions). I setup an account (my username is "nicholas.l.appleton") - but do I have to pay to use Assembla? Their website seems to strongly suggest that I do.
I have been working in a separate repository in my personal github space as I needed a location to push-to and pull-from on a few platforms while I am prototyping and testing. The repo is here: https://github.com/nickappleton/portaudio-cmake-updates and the only file I have modified is the top-level CMakeLists.txt and I've added "cmake_support/FindJack.cmake" to find Jack on Linux. The changes I have made can be viewed in this repository.
The work is incomplete (in the sense of not every Linux hostapi is supported), but I don't expect the structure of the CMakeLists.txt file will change much anymore so hopefully patches after this will be easier to understand. The additions and restructure has reduced the size of the existing CMakeLists.txt.
* I've added support for building PortAudio on OS X (CoreAudio hostapi) and Linux (ALSA and Jack hostapis) and have tested this on OS X 10.11 and Ubuntu 16.04. These can be built the usual way (cmake {portaudio directory} && make), and can also be included by larger CMake projects (a project can "add_subdirectory(portaudio directory)" to have access to the static or dynamic libraries).
* I've restructured the CMakeLists.txt to not pollute global CMake variables (like CFLAGS or include directories) when it is not necessary; this really only has an impact when PortAudio is included in a larger CMake project and prevents libraries which depend on it getting all of the PA-specific compiler definitions etc...
* I've tried as much as possible to keep the existing Windows behavior identical to what it was previously and to not change the look and feel of the Visual Studio solutions. I've also preserved the existing generation of the "options_cmake.h" file - but have not adopted this pattern for the Linux and OS X builds. I have ensured that I can still build PortAudio with Visual Studio 2015 community edition with the ASIO SDK.
* I'd really like to see if I can get CMake to generate an OS X framework for PortAudio. I think this would be pretty cool.
* I want to be able to support "make install" on Linux and possibly OS X if I cannot get the above working.
* I probably should try and get the other Linux hostapis setup - I'm just not entirely sure how I will test them..
---
I hope the new structure is easy to follow and understand. Please let me know about the Assembla business. I am not willing to pay for an account (if that is required) - but if it is not, could someone can reach-out to me off the mailing list to let me know what I am doing wrong.
Cheers,
Nick
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio

[Ross Bencina]

Hi Nick,

Post by Nick Appleton
Is the purpose of passing the PA_XXX_ENDIAN arguments in CFLAGS
purely to provide the endianness for the cases where pa_endianness.h
cannot figure it out?

More or less.

In general we try to minimise the amount of configuration magic required
to make the build work.

In answer to your earlier question: you certainly shouldn't need to pay
for an Assembla account, but maybe you need to be a team member to
submit a merge request, not sure about that. (@Phil: do you know?)

Ross.

[Phil Burk]

Hello Nick,

Thanks for doing this work on CMake for PortAudio. We appreciate it. I
looked at the code on GitHub and it looks nice and clean. I will try and
build on Mac and Linux.

BTW, where is your TestBigEndian script? I couldn't find it.

Regarding Assembla, you should not have to pay. Assembla offers free
repositories for open source, non-commercial projects. In order to submit
Merge Requests, you would need to be a "member" of our Assembla team. We
will contact you about this off-list.

Phil Burk

[n***@appletonaudio.com]

Hi Phil,

Post by Phil Burk
Thanks for doing this work on CMake for PortAudio. We appreciate it. I
looked at the code on GitHub and it looks nice and clean. I will try
and build on Mac and Linux.
BTW, where is your TestBigEndian script? I couldn't find it.

TestBigEndian has been a part of CMake's builtin modules for a long
time. Unfortunately, CMake's online documentation appears to lack the
actual version when it was introduced - but it has existed for at least
6 years if the copyright notice is anything to go by
(https://github.com/Kitware/CMake/blob/master/Modules/TestBigEndian.cmake).

Your question has prompted me to question how old the FindALSA builtin
module is (which I am currently using for ALSA in the Linux builds) -
this appears to be much newer than TestBigEndian and I may need to
retest Linux support using CMake 2.8 and write a FindALSA module if it
does not exist - like I did for FindJack.

Post by Phil Burk
Regarding Assembla, you should not have to pay. Assembla offers free
repositories for open source, non-commercial projects. In order to
submit Merge Requests, you would need to be a "member" of our Assembla
team. We will contact you about this off-list.

Thanks Phil - I appreciate that.

Once I have write access to a branch, I will migrate the changes from my
github across and set up some merge requests.

Nick

[Phil Burk]

I would love to see CMake support for other platforms. Would you make one
giant CMakeLists.txt files or reference platform specific sub files?

If you want to submit a change, please use a Merge Request in the new Git
repository. SVN is frozen.

http://www.portaudio.com/usinggit.html

Phil Burk

Post by Nick Appleton
Hello,
I’m working on expanding PortAudio’s CMake support to cover OS X and Linux
(it will simplify the use of PortAudio in my own projects). I am just
poking the mailing list to see if anyone has fiddled with this before and
whether there is interest in this sort of thing being pushed back into the
mainline once I have it working? I’ve noticed Robert Bielik’s name around
the place in relation to the original Windows CMake support, is it still
being maintained? I’ve been refactoring the CMakeLists.txt file locally to
reduce some of the complexity and have just started to get things building
on OS X. :) I’m also hoping to get “make; make install"-like functionality
working with the CMake generated output if I can.
Nick
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio