Opened 13 years ago

Closed 12 years ago

#347 closed discussion (wontfix)

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

Reported by: Peter Owned by: Peter
Priority: major Milestone:
Component: build Version: trunk
Keywords: Cc:

Description (last modified by 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?

Change History (8)

comment:1 Changed 13 years ago by Peter

Description: modified (diff)

typo

comment:2 Changed 13 years ago by Peter

Description: modified (diff)

comment:3 Changed 13 years ago by Peter

Description: modified (diff)

added relationship to #355

comment:4 Changed 13 years ago by Peter

Milestone: yat 0.x+yat 0.5
Owner: changed from Jari Häkkinen to Peter

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

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

comment:5 Changed 13 years ago by 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.

comment:6 Changed 13 years ago by Jari Häkkinen

Milestone: yat 0.5yat 0.x+

comment:7 Changed 12 years ago by Peter

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

comment:8 Changed 12 years ago by Peter

Milestone: yat 0.x+
Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.