[FR] Projucer basic New CMake Generator

Feature Requests
1

I know this sounds odd :slight_smile:

JUCE already got a separate CMake and that’s great.
But Projucer has very fast “New Project” generator that’s mostly some file templates.

As I see it,
It’s feels pretty low-hanging to make existing Projucer

image
image2024×1480 214 KB

And have a toggle for Exporters/CMake so you could simply get a folder with same generated files (Main.cpp, PluginEditor.cpp/h) and initial CMake setup. (with templates, I already need to do some renaming or write scripts to make a new CMake project…)

2

It would be amazing! (voted)

Although it has to be said, it would be a one way street. You wouldn’t be able to keep edits to the cmake. Well, maybe with some clever private include calls in the CMakeLists.txt

1 Like
3

You’re absolutely right. But the rationale is:

  • For beginners/JUCE first-comers, as stated by JUCE team many times, Projucer is the fastest way to get up and running. Any “newbie” that will export to CMake (by mistake), won’t be able to do much (with the exception of VSCode that might be able to hint some workflow :slight_smile: )

  • For those embracing CMake, many times now, I manually copy some blueprint project and modify it manually. There are some nice usable templates such as @eyalamir 's templates. But in all scenarios, I need to manually rename many things to get to the initial state.

  • Generated project, even in Projucer won’t ensure migration across JUCE breaking changes…

So… for the biggest CMake audience, this feature (I’ll dare say low-hanging) of one-way JUCE CMake generator. is good enough.

But indeed, it’s worth stating if it’s not clear enough that this is one way.

1 Like
4

Are we talking about a CMAKE exporter? I would use this.
I’m interested in moving to cmake for some existing projects, but right now it’s just a bunch of work we don’t need to do.

I get the feeling that JUCE would rather we all move to CMAKE and leave the projucer behind? Is that correct?

5

I’m afraid not.

That’s a complex thing that could easily break. The suggested feature is similar to what you end up creating a new project with Projucer - An empty “skeleton” project.

I’m interested in moving to cmake for some existing projects, but right now it’s just a bunch of work we don’t need to do.

Migrating to CMake requires be acquainted with it first. If you got some grasp of CMake, the migration isn’t that hard even for existing projects.

6

Hmm, I thought that would be the goal too.

In that case FRUT might still be the best bet. This allows to migrate a jucer project to cmake (though I haven’t used it).

I thought this FR would avoid that extra step.

7

We’ve replaced the project generation pipeline in our version of the Projucer to use CMake completely.

What exactly do you mean by empty “skeleton” project?

8

No, each time I make a new project I have to re-write or use my templated of CMake and .cpp/h files.

Let’s say I have SkeletonPluginProject.
So now, for every project I need to rename and refactor pretty much everything.

  • project name
  • classes name (SkeletonAudioProcessor → ActualNameAudioProcessor, SkeletonAudioProcessorEditor → ActualNameAudioProcessorEditor)

Many trivial tasks I could’ve get generated similar to npm create generators flow.

9

I wrote a simple bash script that setup a new juce project for me.

https://github.com/BaraMGB/setup_juce_project

10

Even though I’m one of the few absolute outlaws who think JUCE should make the Projucer much more powerful instead of just treating it as the ‘use it until you know cmake’ thing (because well organized GUI apps just have a much better workflow than text files) I love this idea simply because I could learn more about Cmake from seeing how such an exporter would interpret my Projucer inputs and maybe at some point feel comfortable enough to use Cmake whenever something really can’t and shouldn’t be done with the Projucer

4 Likes
11

A generating app with some UI would be fun.

I would just mention that in my code, I have a much easier time doing manually, due to two patterns.

  1. In CMake, my CMake script starts with:
set(TargetName ActualPluginName)

juce_add_plugin(${TargetName} ...)
target_link_library(${TargetName} PRIVATE juce_audio_utils)
#etc

So I only change a single line when copy-pasting from my template.

  1. In my actual plugin code, instead of MyPluginAudioProcessor, I have:
namespace MyPluginName
{
    struct Processor: juce::AudioProcessor {};
}

So when I’m copy-pasting from my template, I just change the target name in the CMake file, change the namespace in the processor and editor, done.

This can be made faster with a script, but not that much faster, as long as the template has the actual code that you need.

1 Like