CMake support

[MrSapps]

I think it would be nice to have CMake support for easier cross platform compiling?

[arielelkin]

@paulsapps what platforms are we missing?

[MrSapps]

@arielelkin all work that I've compiled for - but CMake allows generation of VisualStudio,XCode,CodeBlocks projects etc.

[arielelkin]

I can't speak for VisualStudio and CodeBlocks, but as far as Xcode is concerned there is support for cocoapods: https://github.com/thestk/stk/blob/master/iOS/README-iOS.md

[erwincoumans]

+1 for cmake, Visual Studio, Codeblocks etc.

[arielelkin]

We have support for make and Visual Studio. make can be used with CodeBlocks.

Is there anything more specific you'd require which can't be done with make?

[MrSapps]

Well on windows nothing beats the speed of using ninja - CMake can target pretty much anything - including generating make files to use with make

[arielelkin]

@paulsapps could you send in a PR for ninja support?

[erwincoumans]

I think the point of paulapps is supporting cmake, not creating another specific solution for ninja, right?

[MrSapps]

Correct, ninja scripts are also not designed to be handwritten..

[radarsat1]

I dislike cmake. My 2 cents.

[arielelkin]

I don't have an opinion on cmake, but I know we have make. And from the discussion above I fail to see what advantages cmake offers over make.

[radarsat1]

I'll be more descriptive, but note that my opinion is totally subjective: I do think the STK make configuration has long been lacking some maintenance.. running "make" and then "make" again causes it to re-run the linker for all the demo projects, and the examples don't re-use the library properly. It also uses Visual Studio-esque Release and Debug directories, but I don't mind this too much.

However, these things can be fixed, or I'd be happy to upgrade the project to automake as we have done for RtMidi and RtAudio. I know that autotools is not to everyone's taste. But I have been made to use CMake on several other projects and although it has some clear advantages, I find it carries enough of its own demons which imho don't make up for what it provides. First and foremost that it is an utterly horrible "language" to program in, much worse even than M4+shell script. Admittedly the Visual Studio and XCode support may be something, but I have yet to understand why people are willing to bend so far backwards to keep things working on Windows and non-FOSS dev environments. I stopped doing so long ago.. if it compiles in MingW that's good enough for me, personally.

All that said, I also think I am not alone in thinking that there is far too much messing around with build systems and the like on the Rt* and STK projects, instead of contributions related to the actual code. Someone comes along on literally every project I contribute to and wants to change the entire build system. This happens all the time lately, and it's tiring. Not just because it's boring to mess with build systems, but because it's more code to maintain. I can point to some projects that have like 3 concurrent build systems just to satisfy people's whims. I guess it's a github thing, because this was a much more rare phenomenon when projects were hosted on Sourceforge. In any case it's annoying to worry about unit testing all of that, my reflex now is to just say "no" to build system changes, unless it actually fixes a build problem.

THAT said, I understand that people have different preferences, and so my policy on other projects has been, if you really prefer CMake, go ahead and propose a way (with a PR) to integrate it gracefully, i.e. keep it in a subdirectory and not interfering with the rest of the project. Think of it as an add-on instead of a replacement. I forced someone to deal with this compromise on liblo and it turned out pretty good.

I'd prefer people just help fix the makefiles that already exist.

[garyscavone]

On Aug 9, 2016, at 10:04 AM, Stephen Sinclair [email protected] wrote:
All that said, I also think I am not alone in thinking that there is far too much messing around with build systems and the like on the Rt* and STK projects, instead of contributions related to the actual code.

I completely agree with this and I myself have been very disappointed and frustrated with how much time is spent dealing with build system issues. The whole point of STK, RtMidi and RtAudio is to offer C++ classes to help simplify audio signal processing programming. How one includes them into a project (pick and choose, library, …) is completely up to you.

The limited build system that comes with STK is there to verify the code works. If others want to make more elaborate updates to the build system, that is ok and we can include them in the distribution, but I would not be in favour if they involve a lot of extra “baggage” added to the distribution and the download of extra binaries to use them (other than what comes standard with most compilers).

[MrSapps]

The benefit of CMake is that you can target any build system, so you still use make after running CMake which generated the make file, or you use CMake to generate sln for Visual Studio and its compilers, or scripts for ninja/CodeBlocks/XCode on mac etc.

On windows using make is a pain with visual studio, in the end you have to create visual studio projects. And you need a project/solution per version of visual studio which is even more painful.

In my use of the STK I just ended up adding the files into a static lib with CMake:

SET(stk_src 
    ${CMAKE_CURRENT_SOURCE_DIR}/3rdParty/stk/src/Delay.cpp
    ${CMAKE_CURRENT_SOURCE_DIR}/3rdParty/stk/src/OnePole.cpp
    ${CMAKE_CURRENT_SOURCE_DIR}/3rdParty/stk/src/FreeVerb.cpp
    ${CMAKE_CURRENT_SOURCE_DIR}/3rdParty/stk/src/Stk.cpp
)

add_library(stk STATIC ${stk_src})

[arielelkin]

Looks good, Paul. Do you think you could send in a pull request?

[MrSapps]

Yeah but it might not be for a few weeks though, I'll get around to it eventually.

[khiner]

I spent the morning figuring out how to get the STK fully working in CLion (which uses CMake only). The following is a full CMakeLists.txt file for a new CLion project on a Mac which should allow most types of STK projects to run correctly. For example, I can copy the "demo.cpp" contents to my "main.cpp" and run it with any needed arguments specified in the "Program arguments" field in the default run config (note that the local directory stk is the git-cloned STK directory):

cmake_minimum_required(VERSION 3.10)
project(project_name)

set(CMAKE_CXX_STANDARD 14)

add_definitions(-D__MACOSX_CORE__ -D__LITTLE_ENDIAN__)
add_library(stk STATIC IMPORTED)
set_property(TARGET stk PROPERTY IMPORTED_LOCATION ${CMAKE_CURRENT_SOURCE_DIR}/stk/src/libstk.a)
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/stk/include/)

add_executable(project_name main.cpp utilities.cpp)
target_link_libraries(project_name stk)
target_link_libraries(project_name pthread)
target_link_libraries(project_name "-framework CoreAudio" "-framework CoreFoundation" "-framework CoreMIDI")

[ryandesign]

However, these things can be fixed, or I'd be happy to upgrade the project to automake as we have done for RtMidi and RtAudio.

@radarsat1 If using automake implies using libtool to make the shared libraries, then I would welcome that as it would fix #86.