Another thing that seems to be a problem:
I have includes between the folders in my library folders.
i.e. /Library/XMLParser/xmlparser.cpp  includes /Library/DebugTools/debug.h

I can solve that by writing the include with the relative folder path: #include "../DebugTools/debug.h

I mean, I could solve everything by doing all my #includes with relative paths... but it should be possible to set the 
include directories properly (as relative paths) and then do the includes normally, right?

Hi, Lorenz,

See some more replies in-line, below.

HTH,

Christian

On Thu, 2010-02-04 at 12:00 -0500, Lorenz Bucher wrote:

> Thanks a lot for your fast reply, Christian.
> 
> Your post did indeed already clarify a lot for me.
> I also re-read some stuff in the IDE user's guide and finally realized that if I create a QNX C++ project and convert 
it to a managed project, it's the same as just creating a C++ project right away. So the difference between the QNX* 
types and the "normal" types is only the makefile/managed project nature. Right?


Well, the QNX Project also relies on a clever library of makefiles in
the SDP target that would have to be supplied to a stock CDT make
project.  There are only a few environment variables required for that.
In any case, it doesn't sound like your problem is related to this.



> I am trying to work with a managed project, i.e. without recursive makefiles. If I understood you correctly, that 
means I'm on the right track by creating a "C++ Project". I only need x86 as target architecture.


Sure, that's the way to go if you're not using the recursive makefiles.



> > Your workspace isn't actually the filesystem root, is it?  I doubt that
> > it would cause problems for the IDE, but you never know ...
> 
> No, of course not..  :-)  I even have a path without any spaces in it, as this is known to cause problems sometimes.


heh heh ... I didn't really think so.  :-)



> > Why don't you also crate a Library project?  That might make it easier
> > to maintain the header and linker dependencies in the IDE.
> 
> I've tried that before, but it doesn't work.. You mean creating a project in the /Library folder and then adding that 
to the workspace, I presume. The problem was that it keeps looking for a main() function in the library project.
> So I created a dummy main function (i.e. int main(){return 0;} ).
> It still can't find the include files.


I thought that the /Library folder was intended actually to create a
library object (.a or .so).  I didn't understand that it was just
sources shared by a number of projects.



> >I've tried adding the source files as source folders... to no avail.
> >>You wouldn't want to do that, because then the source will be compiled
> >>into your Core project's binary, which probably isn't what you want.
> 
> No, that's exactly what I want. My library folders contain not only header files, but also .cpp files.
> 
> The reason I have certain source files in the library folder is that I share them between several projects.
> For example, I can have the /Core and the /Core2 project both using source files from the the /Library folder/project.



Yes, well, this is the purpose of the "source path," to include sources
from some other location in your build.



> I've also tried adding a folder to the Core project and then selecting "link to filesystem folder", but there I was 
unable to use relative paths.


The problem with this is that the filesystem and the make tool don't
know anything about the Eclipse workspace's "linked folders."  They are
just a fiction in the IDE.  Makefiles still require real filesystem
paths.



> If I do this with absolute paths, it says "${workspace_loc:/Core/Library/XMLParser"
> under project properties, but if look under "includes" in the project explorer, I see "C:/QNX640/Debug/${workspace_loc
::/Core/Library/XMLParser", so something is being messed up with the variables, IMO.


I thought that /Core and /Library were sibling folders, not nested?
Perhaps it is simply a typo in your post, but the closing "}" is missing
from your workspace_loc variable expression.  That would case the
makefile generator to be unable to translate it to a real filesystem
path in the makefile, nor to add the correct filesystem path into the
C/C++ Index's include...