-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: never use ..
in a header include
#5321
Conversation
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I'll try to run global testing overnight.
On slack you wrote:
I’m not fine with steps in the middle that are not correct and just might happen to work due to unspecified implementation behaviors.
I didn't look up the rules, but this argument makes a lot of sense to me.
I didn't see any build failures in the global testing (just some flakes, as usual). |
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
* fix: never use `..` in a header include Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com> * fix: one more parent include Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com> --------- Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
So this is why my builds are broken.. |
Please suggest how I should fix: set (PYBIND_INC "/usr/local/lib/${PYTHON_NAME}/site-packages/pybind11/include/pybind11/") This used to work just fine. Now I get:
Just remove the pybind you say set (PYBIND_INC "/usr/local/lib/${PYTHON_NAME}/site-packages/pybind11/include/") That fails with:
|
You are including pybind11 incorrectly. It should be |
also broke our builds... in cmake @henryiii is there an anticipated date when we will only need one include path? |
You don't need two includes. You never include In short, this is correct: #include <pybind11/pybind11.h>
#include <pybind11/stl.h>
#include <pybind11/literals.h>
#include <boost/histogram.hpp>
#include <fmt/core.h>
#include <Eigen/Dense> This is not: #include <pybind11.h>
#include <stl.h>
#include <literals.h>
#include <histogram.hpp>
#include <core.h>
#include <Dense> Also the above CMake snippet, the second set overrides the previous one, so that's actually only one include path. |
Description
You are not allowed to use
..
in a current-directory""
include. This style of include is really designed to allow local files in the same directory (like.inl
files) to be injected into the current location.<>
includes are designed for headers. It's currently working in most cases due to implementation details.This is currently broken, however, if you use a long path prefix on Windows (
\\?\
). For example, if you pass the include as/I:system \\?\C:\pybind11\include
, then the compiler constructs the path as\\?\C:\pybind11\include\pybind11\detail\../thing.h
- but that's invalid, as..
is not processed as a "up one" in a Windows long path, but as a directory named..
. Long paths are being used in specific situations (pypa/cibuildwheel#1975), breaking pybind11 usage.This is the minimum to fix that. Ideally, files should never include something from a parent folder, and (at least) public includes should be included via the public include path, but this is the minimum to fix pybind11 for MSVC.
Suggested changelog entry:
* Fix includes when using Windows long paths (``\\?\`` prefix)