6

In a large project that has files structured in a directory tree structure, is it better to include relative path in source file, or just include header file and instruct compiler via Makefile where to find it?
Is there a preferred way?

Example:

#include "../path/to/file.h"  

vs.

#include "file.h"
gcc -I../path/to  

I believe that first case may be more readable while second approach would give ability to seamlessly move files...

kometonja
  • 437
  • 4
  • 15

2 Answers2

4

The second method is more efficient since you don't have to rewrite the path every single time you want to use this file.

Let's take an example.

You want to build a library containing some useful functions. Then you work on a project on which you need some of the library's functions, not all of them. So you choose to mv some on those files into your project folder.

This way, the path might not be the same, and you won't have to rewrite everything if you choose to include the path in the Makefile.

Coding your Makefile properly, let you have several $(PATH), which is very useful when working on big projects requiring multiple binaries for example.

I'm trying to be as clear as possible, but I really think, in my opinion, that the Makefile is a very powerful tool which can be used to his best to make the project development easier.

Xcrowzz
  • 182
  • 1
  • 19
  • Thanks. I agree with your opinion that make is a very powerful tool. However you did not mention where explicit paths may be useful, I am sure they are not "all wrong" – kometonja Aug 20 '15 at 13:29
4

It depends. For include files inside your project, giving the relative path can be useful, as the sub-directory is another structure-element and you do not have to care about equal file-names (mostly for C++, as C does not support custom-namespaces).

For external paths (e.g. other projects), you should definitively use the second method. Possibly just to the root of that structure. Similar to asm/byteorder.h.

In any way, if using explicit paths (in the source files), you should make sure they are well-documented and any change is tracked to the source files. (There are often common sub-directories, like config, etc. which will not change).

One strong recommendation: always use the project root as working directory. All explicit relative paths are from this root. That way you can avoid the problemativ parent (..) path.

Ultimative rule is not to use explicit paths which cross the project-root.

However, there is no other general rule. The actual layout is often subject to personal preferences. If the directory structure is well-thought, I'd prefer explicit paths.

too honest for this site
  • 12,050
  • 4
  • 30
  • 52
  • This. There is no general rule, but one should think about "namespace" of include files. If you have no subdirectories, you could easily collide with some other name. But it's all policy, there are many ways to solve this. Personally though, I would stay away from paths with `".."` in them though. That can make code reuse harder. Also, there is a case to made for never using `""` but always `<>`, but again, it's preference and policy, no hard rules can help you here. – Prof. Falken Aug 20 '15 at 13:38
  • I think this is more experienced and helpful answer. @Prof.Falken why shouldn't I use quotes for includes? – kometonja Aug 20 '15 at 13:46
  • @Prof.Falken: I think I stated that in the very first paragraph. But as C does not have namespaces itself, you still have to care about the identifiers. For `..` I added something. And for `""` vs. "<>" I disagree. `<>` are for "external"/system includes, while `""` is for project includes. I think the differentiation is clear. (But I agree that the standard should be more clear/strict here). – too honest for this site Aug 20 '15 at 13:48
  • @kometonja, well, for one thing, with `""`, quotes, the file has to be in the same directory as the source. But if you instead have `<>`, brackets, you *can* have them in the same directory as the source (by pointing out with the compiler where they are, with `-I` for gcc for instance) and later decide to put the include files somewhere else. Now, if you had quotes, you have to *also* update all the C files which include them. Also, if we are being picky, quotes actually are weird. See http://stackoverflow.com/a/77092/193892 . The C standard leave it up to the compiler vendor to decide how. – Prof. Falken Aug 20 '15 at 13:54
  • @Prof.Falken: " the file has to be in the same directory as the source" No: The [standard](http://port70.net/~nsz/c/c11/n1570.html#6.10.2) leaves the search-strategy for both to the implementation. And sometimes it is a good idea to have two different search strategies. `gcc -I` does not differntiate between the two version, btw. And about weird-ness: `"` is a normal string-literal delimiter. Perfect for a filename. The `<>`, OTOH are in C++ used for templates - not much related to filenames. – too honest for this site Aug 20 '15 at 14:01
  • Your answer is very good, I was the second person to upvote, if that was unclear. – Prof. Falken Aug 20 '15 at 19:48
  • @Prof.Falken: Thanks (more for the first sentence than for the upvote actually). I hope you did not feel offended or thelike. As a non-native speaker I might not always find the most polite way to comment. – too honest for this site Aug 20 '15 at 23:26