New Introjucer command-line option: --fix-broken-include-paths

Just an FYI about a tool I just wrote (because I needed it myself).

You can now run this:

Introjucer --fix-broken-include-paths [folder]

What it does is:

- Find all the source-files within that folder (recursively)

- Look at all the #includes in those files

- If any of those #includes are broken - i.e. if the path doesn't resolve to a file that exists - then it will search for the filename amongst all the other files in the folder, and if it finds a match, it'll fix that #include to use the correct relative path to this file

The point is that if you have a big project with lots of sub-folders, this will automatically fix any broken includes paths in them. So if you're refactoring a project by moving files or folders around, or renaming the folders, then rather than manually fixing all the broken paths, this will just sort them all out in one go!

Obviously it ain't perfect.. If you have multiple files in the same folder with the same name then it stands a chance of picking the wrong one. And it's not a real preprocessor, it just naively looks for "#include" as a string, so any #ifdefs are ignored. But I've found it very useful for some restructuring I've been doing.


Oh.. and another use-case for it:

Xcode is really lenient about resolving includes - generally, it lets you just name a file without a relative path and it'll find it as long as it's part of your project.

So I constantly hear people saying "why does this #include compile on Xcode but fail on Windows/Linux?". Well, if you're using Xcode and run this tool on your project before attempting to build on other platforms, it should fix these problems automatically.

1 Like

Related to this "feature" in Xcode, I vaguely remember that there is the possibility to make Xcode behave itself and make it deal properly with include files and paths.

I am not at work now, so I cannot provide the precise details, but I may recollect it if you think it is worthy for a post (maybe in a sticky topic), or even to be integrated in the Introjucer-generated code to enforce proper header discipline.

Nice one Jules!

Related to this "feature" in Xcode, I vaguely remember that there is the possibility to make Xcode behave itself and make it deal properly with include files and paths.

thanks, I did not know about such a setting. let us know where it is when you're back to work :)

Ok, I've found it.

You should "Add User-Defined Setting" in the build settings for your project, then enter "USE_HEADERMAP" as the name of the setting, and "NO" for its value.

(I found this when still I was using Xcode 3, I haven't actually checked if it is enforced in Xcode 7 because I'm still using Xcode 6, but I think you can easily confirm whehter this flag is still doing its job or not)

Nice! Thanks a lot!

not sure about xcode 7, I'm still on 5 blush

You should “Add User-Defined Setting” in the build settings for your project, then enter “USE_HEADERMAP” as the name of the setting, and “NO” for its value.

Is it possible to define it from the .jucer project or does this require to be hacked into the Projucer? (so that I don’t have to change the setting each time I regenerate the Xcode projects)

EDIT: found

1 Like

So, (just spotted this thread) would this fix the issue I just spotted on Linux : If I create a new Linux Export target (e.g. ton one of the standard example projects which doesn’t yet have a Linux target defined already), it seems that the JUCE modules path created often (always?) defaults to …/…/…/juce rather than …/…/modules (that is in use by the other targets)?

{or shall I generate a new Linux discussion?}

Just curious: why are you on such old Xcodes and which OS versions are you targeting?

Wondering because it might be relevant to a recent discussion about keeping support for 10.6.

i’m on sierra with last xcode now. not sure about 10.6, I support 10.7 min now…

Ah oops I didn’t notice that this isn’t a new thread… :slight_smile:

Nevermind, I will respond anyway because I think it is relevant to the spirit of your question.

We are not eager to be early adopters of whatever latest version comes out of Apple, because it has already happened that doing so resulted in breaking some sort of backwards compatibility, so we tend to do so at a slow pace.

Just to give you a picture, in my team I am still using Xcode 7 on OS X 10.11, while one of my colleagues has updated to macOS 10.12 but still has to switch over to Xcode 8.

As for the OS version that we are targeting, our Xcode projects still have 10.5 as their deployment target because basically there is nothing preventing us setting it that low. Should some breaking change happen, I think we would be satisfied to support at least up to 10.7.

Also consider that the majority of plug-ins that we maintain these days is still built and released also in RTAS format: we have decided not to support that format for new products, but we have yet to release one so we don’t really know how many users will complain for the lack of it.

Now that I think of it, the main factors holding us back are actually AVID related, both because of this RTAS thing, and also because the latest breaking changes we experienced, caused by updating either Xcode or OS X, have happened in relation to digital signing of AAX plug-ins.

Also, it is my gut feeling (but I don’t have data supporting it, just an impression due to responding to a number of support requests) that the less inclined to update their OSes are Pro Tools users.

1 Like