Open colugomusic opened 1 month ago
At the moment, you can disable the NAppGUI cast()
macro, before include boost.
#if defined(cast)
#undef cast
#endif
#include "boost.h"
At the moment, you can disable the NAppGUI
cast()
macro, before include boost.#if defined(cast) #undef cast #endif #include "boost.h"
This would not make any difference, because the issue is not cause by the order of includes. It is caused by the mere existence of nappgui's "strings.h" in the compiler's list of paths to search for header files.
If you look at the include list I posted above, you will see that nappgui's strings.h is being included by the system's /usr/include/string.h. There is nothing that can be done in code to fix that. Your #undef cast
would have no effect because when the boost header is included on the next line, nappgui's strings.h would then be incorrectly included and cast
would be redefined.
To make matters worse I don't think it is even possible to force cmake to add `-I/usr/include" to the compiler flags before everything else, to ensure that the system headers are found first.
"strings.h" is a standard POSIX header file name so I think it should be renamed to avoid conflicts like this, since there doesn't seem to be any workaround (at least in a cmake build).
This file can cause build problems because it shares its name with a standard header, for example in my project:
As you can see, because
/nappgui/.../src/core/
is included as a header search path, for some reason GCC 13 tries to use nappgui'sstrings.h
first, instead of the systemstrings.h
. I'm not sure yet if there is an easy workaround for this.It may also be wise to add a namespace prefix for macros such as
cast
defined inconfig.hxx
, for examplenappgui_cast
, to avoid the potential conflict also shown above.