Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid include paths #15

Closed
lmdsp opened this issue Jun 12, 2018 · 3 comments
Closed

Invalid include paths #15

lmdsp opened this issue Jun 12, 2018 · 3 comments

Comments

@lmdsp
Copy link

lmdsp commented Jun 12, 2018

Many files have includes which cause build errors if additional include paths are not defined / amalgamated builds.

For example in plugininterfaces/base/funknown.h:

#include "pluginterfaces/base/fplatform.h"
#include "pluginterfaces/base/ftypes.h"
#include "pluginterfaces/base/smartpointer.h"

There is no need to repeat the "pluginterfaces/base part as they're in the same folder !

This works fine:

#include "fplatform.h"
#include "ftypes.h"
#include "smartpointer.h"
@ygrabit
Copy link
Contributor

ygrabit commented Jun 18, 2018

This is the way we choose some years ago...this will be not changed... root is defined as include path.

@ygrabit ygrabit closed this as completed Jun 18, 2018
@lmdsp
Copy link
Author

lmdsp commented Jun 19, 2018

@ygrabit That's a pity, it seems overly complicated and error prone to reference an include from the same folder by going up to root and then down again. Also needs a lot more typing whenever files are moved around .. Just my 2 cents

@aclex
Copy link

aclex commented Jun 19, 2018

@ygrabit @lmdsp I'm actually not so critical on the existing approach, it even looks less problematic and confusing to me, considering namespace features of C++. Filesystem structure usually reflects the namespace hierarchy in the code, so it's quite often, that you have some types of usual name (e.g. device or buffer) here and there in different namespaces in the corresponding files, and only more qualified names allow one to avoid collisions. Generally, the more relative includes are, the more they depend on the include path of the compiler. I agree, that there's no problem with relative includes in the same directory, but, in my opinion, existing includes look equally neat.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants