View Single Post
Posts: 13 | Thanked: 3 times | Joined on May 2010 @ Russian working in Poland for an US company :)
#8
Originally Posted by gri View Post
I've never added "../" to HEADERS.

In my opinion there is no reason to do this. If you want to use the code of a directory "upper", make a shared/static library of them. On this way you also see the headers and sources.

If you don't like that solution, create a "whatever.pri" which contains "HEADERS += $$PWD/header.h" and in your project which is using it add "include(../../../whatever/whatever.pri)"
My situation is like this:

I have a set of directories that contain cross-platform code (without .pro files) and a set of directories that hold platform-dependent code (and .pro files - but some projects use different build systems) for various platforms. It's basically like:

Code:
/libraries/
   /math
   /utilities
   /objects
   ...

/projects/
   /maemo
      ... (maemo projects)
   /pc
      ... (pc projects)
   /ps3
   ...
So projects often refer to files in /libraries directory and its subdirectories (even libraries still have their .pro files under /projects because they are often platform-specific - merging all the possible setups in a single .pro file would make it messy and also vulnerable to breaking compilation for some platform and not noticing it), but in order to get there without using absolute paths (I want minimal setup on different OSes without environment variables etc), I have to use relative paths.

If you think that's totally wrong, I'd be glad to hear your propositions, but we probably should not spam this thread (perhaps private msg would be better?)

Originally Posted by gri View Post
By the way: If you ONLY add headers which don't even contain Q_OBJECT macros, this is just for beauty and doesn't mean anything for the compiler. (I suppose you know that )
Yeah, that's why I said that including files in HEADERS was sometimes necessary I forgot the exact reason and now you reminded me, thanks!

Anyway, I'm really glad that this issue will be fixed in the next MADDE. Thanks to the dev team!

Last edited by RCL; 2010-05-25 at 10:33.