Include headers relative to -I

[tpadioleau]

• simplifies the logic: always relative to the root,
• should better avoid clashes with namings like "macro.hpp" or "config.hpp" that other projects could also define.

[cedricchevalier19]

Most of the changes are making things slightly worse. We probably should gather more documentation on how to deal with #include before committing to a choice.

[cedricchevalier19]

Not sure this change is sound. Using "macros.hpp" will make the compiler look for a macros.hpp file in the current directory and not to browse the whole path list of includes.

[cedricchevalier19]

"source": https://blogs.stonesteps.ca/1/p/64

[cedricchevalier19]

Suggested change

	#include "ddc/ddc.hpp"
	#include <ddc/ddc.hpp>

Here ddc.hpp is not in a ddc subdirectory of the current kernels directory.

[cedricchevalier19]

If you go this path, I think <> is more appropriate.

[cedricchevalier19]

I think this change is not necessary.

[cedricchevalier19]

Same here

[tpadioleau]

Most of the changes are making things slightly worse. We probably should gather more documentation on how to deal with #include before committing to a choice.

Well a choice was made when we started the project. Of course we can change it if there is a better choice. Here is my understanding of the choice (note that I may have again misunderstood this choice):

• we use double quotes for internals headers to actually show they are part of the project,
• we rely on the search path of the compiler, see CMakeLists.txt the include path is injected in the build interface of the target.

[tpadioleau]

Back to draft the time we get consensus

[tpadioleau]

@cedricchevalier19 What do you think if:

1. we use double quotes for the internals of the core part
2. for the components FFT, PDI, Splines use <ddc/ddc.hpp> and double quotes for their respective internals

Regarding 1., an issue is about the experimental directory that depends on the parent directory. An easy solution is to remove it as it is not used at all for now but it does not solve the issue on a longer term. We could also introduce a new directory core so that we would have:

ddc/
├── core
├── ddc.hpp
├── details
├── experimental
└── kernels
    ├── fft.hpp
    ├── splines
    └── splines.hpp

Let me know if you have better ideas.

[tpadioleau]

Other idea:

ddc/
├── CMakeLists.txt
├── include
│   └── ddc
│       ├── ddc.hpp
│       └── impl
│           ├── detail
│           └── some_header.hpp
└── tests

with components:

ddc_fft/
├── CMakeLists.txt
├── include
│   └── ddc
│       ├── fft.hpp
│       └── impl
│           ├── detail
│           └── some_header.hpp
└── tests

[cedricchevalier19]

Other idea:

ddc/
├── CMakeLists.txt
├── include
│   └── ddc
│       ├── ddc.hpp
│       └── impl
│           ├── detail
│           └── some_header.hpp
└── tests

with components:

ddc_fft/
├── CMakeLists.txt
├── include
│   └── ddc
│       ├── fft.hpp
│       └── impl
│           ├── detail
│           └── some_header.hpp
└── tests

I think this approach is easy to enforce if you are ok dealing with deep file hierarchies.

[tpadioleau]

I think this approach is easy to enforce if you are ok dealing with deep file hierarchies.

Are you aware of difficulties with deep file hierarchies ?

In a such a config there would still be one file that I don't really know how to handle which is config.hpp generated by cmake in the build directory. At the build stage it should be #include <config.hpp> because it would be found by specifying the path to the build directory. But once installed we could #include "config.hpp" because it gets copied with the rest of headers.