frang75 / nappgui_src

SDK for building cross-platform desktop apps in ANSI-C
https://www.nappgui.com
MIT License
488 stars 50 forks source link

strings.h should be renamed to avoid standard library conflicts. #153

Open colugomusic opened 1 week ago

colugomusic commented 1 week ago

This file can cause build problems because it shares its name with a standard header, for example in my project:

In file included from /home/chris/dv/env/prefix/include/boost/fusion/iterator/deref.hpp:11,
                 from /home/chris/dv/env/prefix/include/boost/process/v1/async.hpp:41,
                 from /home/chris/dv/env/prefix/include/boost/process/v1.hpp:9,
                 from /home/chris/dv/env/prefix/include/boost/process.hpp:27,
                 from /home/chris/dv/cpm_cache/scuff/a4159ed6e8606db8a050dca7dafd4360317f0ddb/common/include/common/os.hpp:82,
                 from /home/chris/dv/cpm_cache/scuff/a4159ed6e8606db8a050dca7dafd4360317f0ddb/test-host/src/main.cpp:1:
/home/chris/dv/env/prefix/include/boost/fusion/support/iterator_base.hpp:22:14: error: macro "cast" requires 2 arguments, but only 1 given
   22 |         cast() const BOOST_NOEXCEPT
      |              ^
In file included from /home/chris/dv/cpm_cache/nappgui/b51a6f10f9b7255fd2367215f1947aa7747ab7e4/src/sewer/sewer.hxx:17,
                 from /home/chris/dv/cpm_cache/nappgui/b51a6f10f9b7255fd2367215f1947aa7747ab7e4/src/osbs/osbs.hxx:17,
                 from /home/chris/dv/cpm_cache/nappgui/b51a6f10f9b7255fd2367215f1947aa7747ab7e4/src/core/core.hxx:17,
                 from /home/chris/dv/cpm_cache/nappgui/b51a6f10f9b7255fd2367215f1947aa7747ab7e4/src/core/strings.h:13,
                 from /usr/include/string.h:462,
                 from /usr/include/c++/13/cstring:42,
                 from /home/chris/dv/env/prefix/include/boost/assert/source_location.hpp:15,
                 from /home/chris/dv/env/prefix/include/boost/exception/exception.hpp:9,
                 from /home/chris/dv/env/prefix/include/boost/throw_exception.hpp:21,
                 from /home/chris/dv/env/prefix/include/boost/process/v1/detail/config.hpp:34,
                 from /home/chris/dv/env/prefix/include/boost/process/v1/detail/basic_cmd.hpp:10,
                 from /home/chris/dv/env/prefix/include/boost/process/v1/args.hpp:33,
                 from /home/chris/dv/env/prefix/include/boost/process/v1.hpp:8:
/home/chris/dv/cpm_cache/nappgui/b51a6f10f9b7255fd2367215f1947aa7747ab7e4/src/sewer/config.hxx:156: note: macro "cast" defined here
  156 | #define cast(ptr, type) ((type*)(ptr))

As you can see, because /nappgui/.../src/core/ is included as a header search path, for some reason GCC 13 tries to use nappgui's strings.h first, instead of the system strings.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 in config.hxx, for example nappgui_cast, to avoid the potential conflict also shown above.

frang75 commented 1 week ago

At the moment, you can disable the NAppGUI cast() macro, before include boost.

#if defined(cast)
#undef cast
#endif
#include "boost.h"
colugomusic commented 1 week ago

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).