-
-
Notifications
You must be signed in to change notification settings - Fork 23.6k
SCons: Add CPPEXTPATH for external includes (reverted)
#104893
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
SCons: Add CPPEXTPATH for external includes (reverted)
#104893
Conversation
ce24073 to
3245dd4
Compare
|
Hmm, so the different platforms handle thirdparty includes differently. That's... Annoying |
|
That looks pretty promising! I like the idea. I had missed the previous attempt.
What do you mean exactly? |
|
The CI build with SCons 4.0.0 has a type error: |
Oh! That must've been what was throwing me off earlier. Hopefully it's not a platform-specific issue after all |
3e3ec71 to
fb6e95c
Compare
|
|
||
| #ifdef MODULE_MSDFGEN_ENABLED | ||
| #ifdef _MSC_VER | ||
| #pragma warning(disable : 4458) |
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.
This might cause warnings to be raised by the GDExtension build option for text servers, CC @bruvzg.
We might want to add the same system to godot-cpp.
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.
I'll make a followup PR there once this is merged
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.
It likely will, but godot-cpp does not use Werror in any config, so it won't break it. But it definitely worth adding the support for the same system to godot-cpp regardless.
akien-mga
left a comment
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.
Looks great!
fb6e95c to
f25fc34
Compare
This was lost in godotengine#104893 when removing the warning ignores no longer relevant when including the D3D12MemAlloc _header_ as external. But we still compile the .cpp directly and it has this warning. Clarified why have a wrapper for this file.
This was lost in godotengine#104893 when removing the warning ignores no longer relevant when including the D3D12MemAlloc _header_ as external. But we still compile the .cpp directly and it has this warning. Clarified why have a wrapper for this file.
This was lost in godotengine#104893 when removing the warning ignores no longer relevant when including the D3D12MemAlloc _header_ as external. But we still compile the .cpp directly and it has this warning. Clarified why have a wrapper for this file.
This was lost in godotengine#104893 when removing the warning ignores no longer relevant when including the D3D12MemAlloc _header_ as external. But we still compile the .cpp directly and it has this warning. Clarified why have a wrapper for this file.
This was lost in godotengine#104893 when removing the warning ignores no longer relevant when including the D3D12MemAlloc _header_ as external. But we still compile the .cpp directly and it has this warning. Clarified why have a wrapper for this file.
This was lost in godotengine#104893 when removing the warning ignores no longer relevant when including the D3D12MemAlloc _header_ as external. But we still compile the .cpp directly and it has this warning. Clarified why have a wrapper for this file.
This was lost in godotengine#104893 when removing the warning ignores no longer relevant when including the D3D12MemAlloc _header_ as external. But we still compile the .cpp directly and it has this warning. Clarified why have a wrapper for this file.
This was lost in godotengine#104893 when removing the warning ignores no longer relevant when including the D3D12MemAlloc _header_ as external. But we still compile the .cpp directly and it has this warning. Clarified why have a wrapper for this file.
|
This is causing problems on nixpkgs, where we build for linux with sowrap disabled and with builtin freetype. One of the pkgconfig dependencies ( This results in a link error: There are various ways this could be fixed, but I'm not sure what approach to take. #109749 seems similar, and resulted in reverting the CPPEXTPATH change. |
|
Shoot, it seems like this setup really struggles to account for dependencies defining includes in different styles. It might warrant revisiting this system altogether, which is annoying but I don't want this to be a recurring issue |
I'm not sure the old way was any more 'right' in general. In my build environment, I have: What if the vendored freetype causes problems with fontconfig? I think what I'd like to do in nixpkgs is just turn off as much of the builtin_ stuff as possible. |
|
We should revert this given the number of regressions it's causing, for limiting benefits. See: |
CPPEXTPATH for external includesCPPEXTPATH for external includes (reverted)
A reimagining of the above PR. Instead of adding a dedicated method for external includes, this instead opts to add an entirely new SCons variable to append pathing to. This keeps the existing logic almost completely unchanged, with only generic renames being needed most of the time. Much like the previous PR, this removes the need for the warning wrappers around external includes, so those have been removed as necessary.