Xcode run arguments environment variables

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:

Is that even possible? When generating the Xcode project files, the xcscheme

PROJECT_NAME.xcodeproj/xcshareddata/xcschemes/whatever.xcscheme

does not even exists. This is the file where the environment variables are saved when using the Xcode scheme arguments UI.

I even tried to export env vars via post build shell script, but it does not work.

Background:

I want to set two env vars:

  • OPENSSL_armcap=1
  • OS_ACTIVITY_MODE=disable

Only the first one is important, otherwise we can not debug via Xcode the amr64 slice of our universal app which uses openssl universal binary.

You can enable “Keep Custom Xcode Schemes” in Projucer to make it keep your changes instead of overwriting them.

2 Likes

Isn’t Projucer going to be deprecated at some point in favor of CMake?

Isn’t Projucer going to be deprecated at some point in favor of CMake?

tldr? Do you mean to mention that there are people that wish that it wouldn’t be deprecated?

We don’t have any plans to deprecate the Projucer at the moment.

3 Likes

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.

We already thought about to switch to cmake, but there are currently other tasks to do :wink:

I guess with cmake it would be possible to do that because we could set CMAKE_XCODE_GENERATE_SCHEME and then add the needed env vars.

Ah, now an idea pops up. Maybe it is possible to run a pre-build script which adds the env vars to the xcscheme file? I will try that.

Yes.

Thanks!

1 Like

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.

But I have been wrong before…

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 :sweat_smile: