Include search path and libraries

[X-Ryl669]

Ok, it has been discussed in the past, but I couldn't figure out what is the current state (or I can't find a working state).

When in the new Jucer, I set a "header search path", I can't figure out how relative it is from the current project (or it doesn't work, since I don't see this path in the output XCode project).
Ideally, this should also be in the main project tab (not in the debug/release one, since for 99% of people, it'll be the same for both configuration), just don't remove the existing one and add a "+" button that pop up a file browser dialog to select the folder.

Similarly for the final libraries to link with. I've tried to put -L and -l in the GCC based specific linker line, but it's a bit counterintuitive, if you need to know the command line of the tool, why should we use a front end?

If you want to be high level, you'd add a "Dependencies" tab/dialog, where one would select the include paths + libraries to build with. The Jucer would then add a common include path for all exporters, but add a per-exporter library link command.

If you have additional resources, it could go there too.

[jules]

Yes, the header paths probably need a bit of thinking about.. Since they're obviously dependent on the target build machine, maybe it'd be better just to have them only in the platform-specific sections, and not in the debug/release settings..?

I've actually never used the header paths in any of my own projects, which I guess is why they don't make much sense. What kind of things are you using them for?

[X-Ryl669]

I don't think header path is dependent of architecture. Almost all libraries' headers are platform independent and rely on the preprocessor to select the right functions.

However, the libraries themselves are platform dependent.

So, ideally, I would do something like this:
In a "Dependencies" tab, I'd add such text box:
- Common library include path (one per line)
- Common libraries to link with (one per line)
- Resources (files to convert to C code and embed in final binary)
- Icon

Example file hierarchy for a generated project
Root Project Dir
\==> Sources
\==> Resources (pictures, sounds, and all other file converted to C code for embedding)
\==> Libraries (the common headers for the external libraries)
\==> Builds
\=====> MacOSX (in there put the precompiled binary library for MacOSX)
\=====> Linux (ditto, could have both i386/amd64 version)
...etc...

The other tab (exporters) should stay the same, in case one really want to include a per platform library path.

When you start using some third party library (like FFT libraries, MP3 decoder, etc...), you usually include a file "lib.h".
Because we want clean code, it very rare that a #ifdef PLATFORM is required, all the stuff is usually hidden in the library header, so the design stays simple.

[jules]

I'm not saying the headers will be different on different machines, but their paths certainly will - e.g. "c:\mylibs\somelibrary" and "~/mylibs/somelibrary"

[X-Ryl669]

Ok
That's why putting a relative path here is a good idea. (Ideally, I should click on a folder button, select a darn real folder, and let Juce compute the relative path from the project and store that instead).
Then one can zip the whole project folder, send it and well, it's working.

[dinaiz]

Ok
That's why putting a relative path here is a good idea. (Ideally, I should click on a folder button, select a darn real folder, and let Juce compute the relative path from the project and store that instead).
Then one can zip the whole project folder, send it and well, it's working.

Yep, I second this !
Generally people will have a directory structure like this :

project\lib1
project\lib2
project\juce
project\ownProjectcode

this could sit in c:\ or in ~/ but the relative paths will be the same