We’ve transferring .jucer files around between users on different systems using version control, and this is proving a pain.
The reason is that the new Jucer has commands looking like “Save and Open in XCode” - but no “Open in XCode” (i.e. no way to generate the files without also doing a save).
Due to line endings, and independently due to the fact that we’re automatically re-generating our .jucer files, every line in the .jucer file changes, and we’re endlessly checking these in and mucking up our history, and worse, losing changes (because “merging” is basically impossible).
Since I’m here I thought I’d ask how the effort in having variables available in the forms is going…?
After the last time we discussed this I added the ability to use any of the preprocessor definitions inside the other text fields using a $(foobar) syntax, and provided places to override the preprocessor defs at different levels. There should be more info about it in the rollover help!
RIght on SQUARED because the new preprocessor syntax will solve all my remaining build issues and I can just sit back and watch the code write itself. (What, you don’t have that feature yet??)
Hmm, it seems as if getHeaderSearchPaths() isn’t getting replacePreprocessorTokens()-ed!
(It’s logical to do that because header search paths might well be different on different systems.)
I’ve only read the code, not actually run it but the change looks pretty easy and I’ll just do it here and test it (I’m at the tip right now, is there an easy way to throw you a delta?)
So I don’t think this covers my supposedly-very-generic use case: one application built for Mac and PC platforms that uses several libraries.
Trouble 1 is the location of the header path variables, which are found individually in the Configuration.
In my experience, the header path is at least as likely to vary between platforms as the linker flags - certainly my Mac header path is quite different from my Windows header path. Moreover, it seems to be extremely likely that the header path will NOT vary between configurations.
So there’s no direct way in this to have different header paths for different platforms - which is my main use case.
I have a hack for Trouble 1 too tedious to describe but then I run into Trouble 2 - there are two different sorts of variables that are conflated here.
The first type of variables are “defines that are passed to the C++ compiler”; the second type is “variables that are used in the substitution phase of the Jucer”.
Basically, any possible definition I make to try to substitute those header lines correctly in Jucer ends up not even being a legal definition for C++.
I don’t see any need for the overlap. It seems to me that these are two different cats entirely - if I want to do substitutions in Juce-land when generating build files, I don’t want these to be variables in every C++ file I compile, and conversely I don’t have any need to substitute in C++ defines into Juce.
My thinking was to have a set of variables that ONLY existed in Juce-land but that could be substituted everywhere - even in the “preprocessor definitions” list. If you needed one of the Juce-variables in a C++ define you could simply put SOME_VARIABLE=${SOME_VARIABLE} in your “preprocessor definitions”.
EDIT: I have a hack to the experimental Jucer that prevents it from passing defined variables that start with __ to the C++ preprocessor - and it all works! Fairly sure this isn’t the best way to do things but perhaps…?
Hi Tom, sorry for the delay in replying. I’ll sort out the header paths thing; not entirely sure what the best plan would be for the other stuff, but TBH your hacky “__” prefix doesn’t sound too bad to me…
Jules! Never apologize for “slow” responses, you devil you… You’re a hero around these parts.
The __ solution actually came out very neatly and I closed this whole bug in our own system. The new features let me remove a couple of hundred lines from our own scripts too.
That’s really not a bad solution. The code delta is small. You aren’t supposed to use variable names starting with __ for your own purposes in C++ so there is no issue with collisions. Having two different pools of variables is somewhat confusing.
Running a locally hacked Jucer is ZERO issue for us - we have a deliverable at the end of the year, and I see absolutely no need to change the Jucer code before that.
I’d actually suggest one more change, which I’m going to implement fairly soon just for neatness, and that’s that you keep resubstituting until there are no substitutions (with a counter in case someone foolishly has self-recursive definitions).
The reason is simple - sometimes your variables need to know about which config they are in… sample:
I thought I’d ask how the effort in having variables available in the forms is going…?