#includes: "yat/utility/utility.h" or "../utility/utility.h"

[Peter]

Related to ticket:336 and ticket:355

When including a yat file from another directory, I think we decided to follow the former format

#include "yat/utility/utility.h"

I'd like to resurrect that discussion. The reason is two-fold.

• I would like to solve problem that wc yat includes installed yat when a file is missing (#336). For example say that you delete iterator_traits.h. Then when you pp the file cannot be found locally, so instead the installed file will be included. This means everything will work although the build is broken. In case of BAD LUCK this will pass through all the way through make distcheck and a very embarrassing dist is released. This is just one example how we may fail to detect error because installed yat header files are included. If we change to includes a la `#include "../utility/utility.h", I think installed files cannot be included in that case.

• Second argument is just a minor thing. In apr guidelines ​http://apr.apache.org/versioning.html that we intend to follow (ticket:231), they say that in order to allow users to install multiple versions of a library simultaneously, one should consider to install header files as /usr/local/include/yat-MAJOR/ rather than /usr/local/include/yat. Well, we are far from a a yat 1.0 release (!!?), yet it could be beneficial to allow multiple installations. I'm not suggesting we should rename the include dir, but if we change include style, we'll allow user to manually rename the include dir. As now that is not possible because if we change name of dir yat, internal yat includes will not work across subdirs.

Opinions?

[Peter]

typo

[Peter]

added relationship to #355

[Peter]

Obviously, I wanna change to #include "../utility/utility.h"

This would also mean that we should remove @top_srcdir@ from include path.

[Peter]

Second argument above is not really valid.

The reason is that you could have an include structure as recommended ​here:

/usr/local/include/yat-0/yat/utility/Vector.h
/usr/local/include/yat-1/yat/utility/Vector.h

and then you would need to add a -I/usr/local/include/yat-X to your preprocessor.

This design would allow parallel installations, and it also makes it easy to upgrade a project from yat-0 to yat-1: by changing only changing preprocessor and linking flags.

The drawback is obviously that header files are not in built in include path and -I/... has to be added to preprocessor. This would not be the case having a structure recommended by ​APR

/usr/local/include/yat-0/utility/Vector.h
/usr/local/include/yat-1/utility/Vector.h

in which case the second argument above is valid. The good thing here is that in one project you can mix yat-0 stuff with yat-1 stuff, and there is a firewall between them so they will not intrude. On the other hand, it is not as easy to upgrade from yat-0 to yat-1, because you need to modify all your includes.

[Peter]

Seems like having '..' in include is considered bad style, so I guess the alternatives are include "yat/dir/file" and include "dir/file"

[Peter]

Include "dir/file" would not work because preprocessor would not find file.

Another reason to to keep it as is would be that it is just tedious to change all inclusions.

A third reason to keep it as is would be that this is how boost does it.