Closed SadieCat closed 1 year ago
How are you specifying Lyra headers as search paths in your project? Are you using -I
, -isystem
, or something else?
I'm using data/single_include/lyra/lyra.hpp
and it is in a directory that is added to the search path with -I
.
Have you tried -isystem instead?
On Wed 27 Jul 2022, 23:19 Sadie Powell, @.***> wrote:
I'm using data/single_include/lyra/lyra.hpp and it is in a directory that is added to the search path with -I.
— Reply to this email directly, view it on GitHub https://github.com/bfgroup/Lyra/issues/66#issuecomment-1197431644, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFTGN72CAL7WK5TWUAFJMLVWGYXVANCNFSM5T2HBKAQ . You are receiving this because you commented.Message ID: @.***>
That hides the warnings for me but it would also hide warnings for other headers in the same directory and would not do anything for other users who are including the header using a path relative to a source file.
I proposed a better fix for the problem in PR #67.
It ought to be possible always to include 3rd-party headers via -isystem
. It's a flag which is used specifically for this purpose.
Fixing warnings generally is good practice and the intent of #67 is worthwhile. However, as a solution to the problem of using -Werror
in client code, it isn't a permanent or scalable solution.
In the future, new compiler versions (or even new compilers) might introduce new warnings. Ideally this should not break dependencies in code which might be working perfectly as is. Hence, -isystem
which expresses the fact that fixing 3rd-party header warnings is beyond the scope of the dependent project.
As Lyra is a header-only library it is affected by project build flags so there is no reasonable way for a project to work around this short of disabling the flag.
Here is a sanitised log from my project:
I'm using the single header version of 1.6.0 but this should still occur with the multi-header version.