Conan-center-index: Use package folder name as the package for headers

Created on 8 Dec 2019  路  4Comments  路  Source: conan-io/conan-center-index

Coming from: conan-io/cmake-conan#189, also in docs: https://github.com/conan-io/docs/issues/1498

Using a folder for headers is best practice to have includes like

include "mypkg/myheader.h"

instead of only

include "myheader.h"

Does it deserve a hook to check?

Most helpful comment

IMHO this depends on the library itself. If all the documentation about a library says it has to be consumed like #include <qt/qt-feature.h> or #include <qt5/qt-feature.h> or #include <qt-feature.h>, the recipe and the test_package examples should follow the documentation... we cannot enforce it in Conan or it will require patching a lot of consumers.

If nothing is said, we all (?) agree that the pkg/pkg-file.h should be promoted, but a hook by itself cannot know if the library provides some recommended way to consume it or not.

All 4 comments

I want to point out that we have in many packages both include variants, with a directory-prefix and without, because some other package is consuming it without prefix...

But I agree that we probably should always add the prefix variant.

IMHO this depends on the library itself. If all the documentation about a library says it has to be consumed like #include <qt/qt-feature.h> or #include <qt5/qt-feature.h> or #include <qt-feature.h>, the recipe and the test_package examples should follow the documentation... we cannot enforce it in Conan or it will require patching a lot of consumers.

If nothing is said, we all (?) agree that the pkg/pkg-file.h should be promoted, but a hook by itself cannot know if the library provides some recommended way to consume it or not.

I agree keeping a folder as a namespace it's the best approach for avoiding name collision, but not all projects follow it, and adding those virtual folders, can break users, which follow the upstream's structure.

I vote for following the upstream, and, when there is no project folder, add one:

self.cpp_info.includedirs = ["include", "include/foo"] # include/foo is the regular include path

Cons:

  • We will need review it for any PR

Pros:

  • Users can decide if they want or not using the folder.

After the latest comments, can we imagine a hook (or something) capable of doing this kind of check? Shall we close the issue?

Was this page helpful?
0 / 5 - 0 ratings