Recent Change to use bracket <> includes instead of "" includes breaks XCode compiles.

[RamiHg]

Hello,

I noticed there was a recent change to use bracket includes (i.e. #include <xt/...>) instead of regular quotes. This happens to break XCode9 unless you change a deprecated setting called "Always Search User Paths". <> includes are usually implementation defined anyway, and reserved for framework paths.

The GCC documentation, for example, specifies:

For the angle-bracket form #include , the preprocessor’s default behavior is to look only in the standard system directories. The exact search directory list depends on the target system, how GCC is configured, and where it is installed.

Is it possible to revert that change?

Thanks,
Ramy

[SylvainCorlay]

@RamiHg thanks for your report!

I am curious how you install xtl to get this error. Do you install xtl in an installation prefix?

[RamiHg]

Hello,

No, I simply place xtl in my project's private include directories. I don't install any of the libraries (that's the beauty of header-only libraries).

Thanks!

[SylvainCorlay]

No, I simply place xtl in my project's private include directories. I don't install any of the libraries (that's the beauty of header-only libraries).

Gotcha. We need to decide if this use case should be supported. (not saying it should not)

Is there a good reason to no install libraries?

For e.g. xtl:

cd build
mkdir build
cmake -D CMAKE_INSTALL_PREFIX=/path/to/prefix ..

will also place the cmake project configuration files in the right place etc...

[RamiHg]

I would say the biggest reason is self-containment. I.e. not having to worry about different versions of xtl on one's system. Each project that depends on xtl can host its own version. It makes working with dependencies slightly easier.

[SylvainCorlay]

Not that I am opposed to using quotes, but "self containment" is generally not a good reason to vendor your dependencies in a project even when they are header-only, quite the opposite.

As soon as multiple project use heterogeneous versions of these dependencies, and need to link with each others, you will have all kinds of issues from binary incompatibility and one-definition rules breakages.

A generally used method is to have a non-system installation prefix where you install things, and packages of that installation prefix are not allowed to link outside. This is what tools like conda do with environments.