I like to set Xcode run arguments env vars via Projucer. This is the view in Xcode where we have to set them manually and everytime we generate the Xcode project again:
Thats a good option, good to know, but does not fix our use case.
We just add the jucer files to our git repo, then everyone can create their own Xcode project files. Thats why it would be great to be able to save these env vars in the jucer file, so everyone in the team have the env vars already configured and do not have to set them manually.
Thank you! Please accept my vote to not deprecate Projucer.
I understand completely the attraction of CMake for those working in teams and having complicated build environments. But, there are many for whom CMake can be an unnecessary complication.
Also, for new JUCE users, Projucer is the path of least resistance.
I understand completely the attraction of CMake for those working in teams and having complicated build environments. But, there are many for whom CMake can be an unnecessary complication.
I haven’t written C++ without CMake since the first cmake support was released in JUCE, for any project at any scale. There are other tools like meson, but you really are hurting yourself by treating it as unnecessary complexity instead of a fundamental tool for building C++ in the 21st century.
There’s a lot you’re missing, especially if you want to use relatively standard things like boost/abseil/folly, immer, protobufs, safer/faster json parsing than JUCE, etc. cmake is one of the easiest ways to glue that all together today.
Thank you. I always appreciate input from those more experienced than myself.
As it happens, none of those things you mentioned, boost/abseil, etc., apply to my situation.
I build plugins. I build a TracktionEngine based DAW app. The only thing I add is the Steinberg ASIO SDK, everything I need, which is minimal, is easily added with ProJucer. My builds take less than two minutes, often less than one minute.
I am not trying to be argumentative. In my ignorance, I cannot see how CMake will make things “better”. In fact, from all the CMake discussions I have seen on this forum, CMake seems to be a nightmare to use. And so is of value only to those who need the features enough to warrant dealing with it.
That’s fair! The thing for me is that I routinely want to pull in things like gtest and benchmark for even the smallest projects and use cmake to do that, along with most of the C++ I’ve written over the last few years. While JUCE’s cmake integration gives me problems that’s because JUCE is annoying to build, not because of CMake.
Actually it was not my plan to trigger a discussion about deprecating Projucer or Projucer vs cmake.
I just want to put my 2 cents to this topic:
it is up to everyone which build tool they want to use to build their software. If JUCE provides both ways, it is great. For both tools uses cases exist. If you think one build tool needs more support in JUCE, create a feature request or start a discussion in an own thread.
But this FR was a specific question with Projucer and Xcode.
So BTW: I just want to know if this feature request is useful for people and if it is even technically possible. If not, I can close this otherwise a new discussion pops up
