VisualStudio cannot find include files

That’s an Xcode “feature”, but isn’t normal compiler behaviour.

Hah. I am undoubtedly showing that my main development platform is Mac OS X :oops:

It is beyond me how VisualStudio could not implement this feature too. It’s really great to throw a couple things together and make them “just work”. I got so used to this over the years, I didn’t even remember I had to take care for the include directories in VC projects. Now that I think of it, it became clear.

Thanks for bearing with me.

Visual studio is quite right to not implement it, it’s a very bad feature IMHO. To make the behaviour of a compile unit dependent on the structure of the project that’s compiling it feels really dodgy to me.

Asking for bad features is something I am familiar with. My customers keep asking me for many, many bad features that seem to add some extra comfort for them but effectively contradict the entire paradigm of the software. So yes, I think I got the point.

It is still cumbersome that there is no recursive inclusion for VC. If I do not want to flatten all my source trees, I have to grave the directory structure in stone and use physical directory names in all sources. What If some day I decided to reorganize my code trees? Then I’ll have to edit countless files and projects to reflect the change. Very, very static.

Have you seen the juce codebase? That sure ain’t flat, and I reorganise it all the time! I wrote a little utility that takes a folder and fixes all the include paths inside it, and that works a treat.

Yes, I had a look at your structure and applied the same idea to my projects. Thanks for pointing me to that direction.

However, now I have the problem that I can’t seem to include files from the “Common” tree, as these also need to include “JuceHeader.h”, which is project-specific. This disallows a relative path. Therefore I need a plain #include “JuceHeader.h” in there and hope to get this resolved by a compiler directive for inclusion directories (?)

A relative inclusion option does not work, because the particular project is unknown in advance. Does this force me to supply an absolute inclusion path per project? Or is there any trick to use variables for the #include directive?

Man, is this complicated. Some 20 years ago I asked a friend “What is the most characteristic thing about C?” and he answered: “It can not find its header files.” :wink:

Can you share this utility please?

Have a look at SimpleDJ on my Github page. It uses include paths like “$(ProjectDir)…\JUCE”.

Actually, that only works in my non-IntroJucer projects. For IntroJucer projects I use a project-relative path like “…/…/…/JUCE” or “…/…/…/VFLib”.

So yes you can have relative paths in your Visual Studio 2010 project settings.

I’m now trying for the first time to build a project with Visual Studio 2015 that compiles fine in Xcode and am running into the same problem with include files. While I agree that Visual Studio is right not to implement it, for projects to be compatible on both platforms, could not the Introducer (perhaps optionally) compensate by automatically adding additional include directories to VS projects based on the existence of header files in various subdirectories.

One is probably fine if the project started under Windows and then ported to OS X because the #includes will be correct but going the other way around now requires extra work.

(Edit: yes, I can avoid the extra work and just add the include directories to the Extra Preprocessor Definitions area but it would be nice if this was done automatically)

No - I’ve always hated the way people use include paths to refer to internal parts of their project. I’d recommend you never do that, I don’t think it’s a good design decision for Xcode to allow this kind of laziness, and certainly wouldn’t consider adding anything to the Projucer to make it easier!

Two main reasons:

  1. The point of include paths is to let you include files from locations that may change (or are different on different machines). Within your own project, the relationship between your own files is always fixed, so you can always write code that will resolve the files without expecting the project to contain some kind of magic paths for it to work. You should always aim to write code that can be built with as few project settings as possible.

  2. When you write your includes with relative paths, it’s much more informative to the reader - you can immediately see exactly which subfolder each file comes from, and if you’ve organised your project structure cleanly, that will add a lot of semantic information when you’re trying to see what areas of your codebase a file is dependent on. I often also try to sort my includes by the parent folder, so you see a nicely grouped list of files from each subfolder, rather than a flat list of random names which could be from anywhere.

Jules, philosophically I agree 100% with your arguments — the suggestion is purely pragmatic — if you have started from Windows, then it’s not an issue but developing on Mac first and then porting a large project to Windows becomes a major headache because of xcode’s “flexibility” (and consequently a developer’s sloppiness)

Having said that, I’m not sure that Introjucer is supposed to take on the role of proper code design arbitrator or decide what kind of code is readable. That’s for a team to decide. Yeah, hopefully developers will be influenced by the way you wrote the frameworks (it really is superb) but with respect to cross-platform support, the role of Introjucer should be to help make it easy to go from Mac to Windows so an option such as “Lazy header handling” would be useful.

Well, I think in little ways like this we should try to steer people in the right direction! Of course people can always just add their own paths in the projucer, but TBH if I was going to do something to help people in this situation, my preferred option would be to provide a utility that will scan your project files and auto-correct the include statements to use the best canonical paths where possible. I actually have an internal utility that I’ve used for that, which could be cleaned up and added to the projucer’s command-line arsenal.

Jules, if I put my professor hat on, I agree with you 100%, as I said before. It’s just that when I moved from the research world to the financial world (a hedge-fund, where even taking a half hour longer can cost millions, not fun), I learned the pragmatic tradeoff between doing it right (which often takes longer, if the tools aren’t there) and making it work NOW (and hopefully finding time to make it right later). Consequently, I have some sympathy for both views.

But obviously, if you’ve got the tool that allows the include paths to be adjusted automatically, then that’s even better. Any chance you would share the internal uncleaned version (so we can do it right now and we’ll take the beautiful cleaned up version later :slight_smile: )

I would agree if it was an agile in-house project for a specific purpose, but disagree for JUCE and similar platforms. Doing it “right” is the only way for a complex software platform to stay usable and maintainable in the future.

1 Like

FYI, it is possible to disable the Xcode “sloppiness” regarding paths of header files that are added to the project.

To do so, 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.

@jules, Perhaps this could be added as a flag in Projucer, so that it can generate Xcode projects that will enforce correct paths for the inclusion of header files, so that they will already be correct when moved over to some other strict compiler.

That’s a nice idea, but just imagine the moaning we’d get if we added it now and it “broke” people’s existing projects!

That should be enabled by default for newly created projects, disabled for existing ones (for backwards compatibility), and always toggleable at the user’s request.

Oh, and also, now that I check it seems that that setting has been promoted to a proper setting in Xcode 7, named “Use Header Maps”.

So it seems that the manual addition of “USE_HEADERMAP” set to “NO” is only needed for Xcode 6 and before

Hmm. Yes, might be a good setting for us to add. Would come in handy for our own projects too.

1 Like

So, I have this same problem.
However, I assumed that once I had created the VS exporter using the ProJucer, that I could simply add my Source and JuceLibraryCode directories to VS’s Include directories list.

Having added these directories to VS, it is still unable to find any of my header files, despite all of my .cpp and .h files being in the root of my Source directory, i.e. with no sub directories for VS to trip over.

What am I missing? Many thanks

Hello zombie thread, welcome back.

Here’s the situation I’ve got going on, which I’m attempting to solve at the moment:

For Visual Studio (2015, in this instance), including the necessary header search paths in the .jucer project has worked successfully for me when compiling Windows versions of my plugin project. The new issue I am experiencing is, that the text editor for the header search paths in the Projucer, cannot fit all the paths that I need to include (yes, the project is that large)!

I’m aware that I can open the .jucer project with a text editor, and force the paths in that way, but that doesn’t seem correct.

I’m looking for a solution similar to the utility that jules has mentioned above. Has anyone else experienced this?

EDIT: I’m going to write an include header in the style of JuceHeader, which will solve this issue. Clearly, a single include header for all these directories is the right path moving forward.