VisualStudio cannot find include files


#1

It is obvious that I am missing something, but VisualStudio 2005 can’t seem to find my project’s include files, even though I have generated the project with the Introjucer (JuceLibraryCode.cpp compile fine). The projects work fine on the Mac. My source files each include the JuceHeader.h and/or other headers that belong to the project:

#include "JuceHeader.h" #include "OtherHeader.h"

VisualStudio 2005 does not find any of them. What’s that I am missing? Does it matter that the project is located on a network share K:\Dev\Projects… ? I tried relative paths for “Juce Location” and “VST Folder” in Introjucer, to no avail.

The demo projects build fine, btw.

P.S: I should add that my sources are organized in a directory tree structure, all projects sharing a “Common” tree, which is added to each project. The projects specific sources are in a “Source” directory, which is a sibling to “JuceLibraryCode” and “Builds”. I need it this way, because also the “Source” tree is shared between 32 bit and 64 bit projects.


SOLVED: #include needs different path on windows
Header outside "source" cannot be found Linux
#2

Well, unless these include statements are in a file in the same folder as the JuceHeader.h file that they’re trying to load, then how do you expect the compiler to magically know where to look for it?


#3

Just adding them to the project is sufficient for XCode. Shouldn’t also VisualStudio know where all project files are, when it lists them in the project browser?


#4

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


#5

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.


#6

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.


#7

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.


#8

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.


#9

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:


#10

Can you share this utility please?


#11

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.


#12

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)


#13

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.


#14

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.


#15

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.


#16

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


#17

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.


#18

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.


#19

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!


#20

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