In the interest of moving projects around, I think that instead of having
everyone should use
and add the paths for includes (and libs) in the toolchain project file.
In the interest of moving projects around, I think that instead of having
everyone should use
and add the paths for includes (and libs) in the toolchain project file.
it is a bit more friendly that way…
Or we can all adopt a standard directory structure for projects.
I simply put all my projects in /juce/projects/projectname
it makes the most sense, and it can easily be universal.
In C/C++ when you use an external library you use:
and define the paths to external headers in the project options or compiler options
should be used for the project headers with relative paths
Well I for one put all my sample editor projects in one master folder and workspace, then create sub folders to contain each project and source tree. So every time I want to check a new version (Rob likes renaming everything apparently) everything breaks.
It’s really more than just an semantic annoyance or personal preference–ost12666 stated it 100% correctly. Standard includes should be and project includes should be “filename”. And the only time it is appropriate to prepend a relative path to filename is when the file location is known to be fixed relative to the project root, otherwise all paths should be defined in the tool settings or makefile.
next version Ill change all that stuff then.