Let's talk about JUCE and CMake at ADC'18

adc-2018

#1

Last year I attended ADC’17, I presented a poster about FRUT (https://www.dropbox.com/s/livt5zv7pmc6740/FRUT_ADC17.pdf), and I talked about JUCE and CMake with a fair amount of people.

Doing these 1-on-1 discussions was very interesting, but it was hard for me to get a complete overview of what the JUCE community wants in terms of CMake support for JUCE (whether it’s in JUCE itself, in FRUT, or in other projects).

Next week I’m attending ADC’18, and I really want to get that complete overview, so I invite anybody who is interested in talking about JUCE and CMake to a small “meetup” within ADC. I propose to meet on Tuesday, November 20th, 13:15-13:45 (exact location TBD).

If you’re not coming to ADC’18, don’t hesitate to let us know about issues, pain points, wishes and topics that you would like to be discussed. I’ll happily take care of bringing them to the “meetup” and then write down a summary in this thread.

EDIT: changed the “meetup” date to Tuesday, November 20th.


#2

Thanks for doing this, I’m a big fan of FRUT and as an XCode/Visual Studio expat this is something I’d really like to see supported.

The one wish I have is to be able to use find_library or find_package to include a JUCE module into a new CMake project, and to use CMake to avoid requiring the JuceLibraryCode folder altogether.

Something else just to put out there - CMake is widely used, but it’s not the only build system out there. Maybe something worth discussing is how changes to the module architecture could be better ported to different build systems and package management tools.


#3

@Holy_City this is what allows https://github.com/remymuller/juce-cmake


#4

This is something I want to add to FRUT since I created it (when it was still called JUCE.cmake), and that will definitely be part of FRUT in the near future (beginning of 2019, or maybe before). I already have a WIP branch with some experiments (https://github.com/McMartin/FRUT/tree/wip/add-files-for-find_package), but I first need to get answers to a few questions:

  • Should it be find_package(juce_core) or find_package(JUCE COMPONENTS juce_core)?
  • What should the target JUCE::juce_core be? A static library? An interface library that has juce_core.{cpp,mm} as interface sources? An interface library that only has include directories, pre-processor definitions, compiler options and linker flags?
  • Should both myLib and myExe compile juce_core.{cpp,mm} when I write?:
target_link_libraries(myLib PUBLIC JUCE::juce_core)
target_link_libraries(myExe PRIVATE myLib)

plus many other questions about JUCE modules config flags, generating binary data files, and handling the various plugin formats.

This is mainly why I want to talk to as many people as possible at ADC’18!


#5

I’d love to come. As long as it doesn’t conflict with the ADC schedule, count me in.


#6

According to https://juce.com/adc/programme, it’s lunch break between 12:30 and 14:00, so there shouldn’t be any conflict.

However, I will amend my original idea and propose to meet on Tuesday (still 13:15-13:45), so we have more time before the end of ADC’18 to meet again if needed.


#7

I arrived at CodeNode. Come say hi if you want, you can recognize me easily, I have the JUCE logo, the CMake logo and my avatar on my badge.

Tomorrow, let’s meet in the SHIFT room (small room after the ALT/TAB one) at 13:15.

@eyalamir @Matthieu_Brucher see you there.


#8

I have to give you my “requirements” for this!

Typically, I’m thinking of my next demo project for Audio Toolkit, and typically, I’d like to be able to add a JUCE app in my builds.

So definitely

find_package(JUCE)

And then perhaps something that populates the traditional JUCE_INCLUDE_DIRS and JUCE_LIBRARIES, but perhaps also something fancier like:

add_juce_plugin(name SRC ${list of source files} TARGETS VST2 VST3 AAX AU AU3)

and this would create all the proper projects.


#9

@McMartin Just took a look at your poster.
You says you cannot reproduce dev id team settings in cmake but you can

Just do
set_property (TARGET ${PROJECT_NAME} PROPERTY XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "Developer ID Application: COMPANY_NAME (YOUR_COMPANY_SERIAL)")
set_property (TARGET ${PROJECT_NAME} PROPERTY XCODE_ATTRIBUTE_DEVELOPMENT_TEAM "YOUR_COMPANY_SERIAL")


#10

@otristan thanks for taking the time to read my poster. It’s a year old, so quite outdated. Feel free to check the latest state of FRUT on GitHub.

Projucer is doing 2 things with the “Development Team ID” setting:

Maybe writing the DevelopmentTeam attribute is not necessary to get a working Xcode project, but I can’t test that hypothesis because I’m not a Mac developer. I don’t have any Development Team ID. I don’t even have any Apple account.

If you’re interested in making FRUT support the “Development Team ID” setting of Projucer, then please write a comment on https://github.com/McMartin/FRUT/issues/251. Your help is gladly appreciated!


#11

AFAIK this is enough as this is currently what we use and it appears to work fine.

I’m good with https://github.com/remymuller/juce-cmake that fits our need and currently develop for our own usage (aka cmake from scratch with no Projucer project)