Giter Club home page Giter Club logo

Comments (4)

pezcode avatar pezcode commented on June 3, 2024 1

After applying this change, you might run into issues with implicit C headers being included by the C++ compiler. Those headers are not in system/include, but they are in cache/sysroot/include.

The fix can be found in emscripten-core/emscripten#17137, the important part:

if("${CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES}" STREQUAL "")
  set(CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES "${EMSCRIPTEN_SYSROOT}/include")
endif()
if("${CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES}" STREQUAL "")
  set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES "${EMSCRIPTEN_SYSROOT}/include")
endif()

This makes sure that explicitly adding the cache sysroot include doesn't have preference over the implicit C++ include directory.

from corrade.

mosra avatar mosra commented on June 3, 2024

Ah, yes, thanks for the reminder.

There's still the problem with headers/libraries of 3rd party projects installed into Emscripten sysroot getting stale that I didn't have time to investigate further, which is why I didn't merge this patch yet. But, just yesterday, while working on the cursed issues from mosra/magnum#560 I was browsing Emscripten changelog and found this in 2.0.24:

CMake projects (those that either use emcmake or use Emscripten.cmake directly) are new configured to install (by default) directly into the emscripten sysroot. This means that running cmake --install (or running the install target, via make install for example) will install resources into the sysroot such that they can later be found and used by find_path, find_file, find_package, etc. Previously the default was to attempt to install into the host system (e.g /usr/local) which is almost always not desirable. Folks that were previously using CMAKE_INSTALL_PREFIX to build their own secondary sysroot may be able to simplify their build system by removing this completely and relying on the new default.

Yes, we're not using the upstream toolchain, so it doesn't affect us, but what I consider important about this note is that upstream treats installing into Emscripten's own sysroot as the recommended practice. Which means that either they should hopefully know about this potential "stale" issue and having a builtin solution for it (that I'm not aware of yet), or the toolchain handles that somehow (and because we don't use it, we don't have that handled), or there might at least be some issues open about this. I'll try to look back into this when I get time.

from corrade.

mosra avatar mosra commented on June 3, 2024

Closing as resolved, forgot this issue was even here.

Just for the record, the first patch was integrated with various version-dependent modification as mosra/toolchains@d5d7430, and the toolchains submodule was updated in 45282f8. The second patch seems to be not needed -- looking into CMake's CMakeFiles/<version>/CMakeCXXCompiler.cmake in the build dir, the CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES already contains it, together with others. I suppose CMake extracts it via emcc -E -v - as it already does for other compilers.

This is for example with CMake 3.17 and Emscripten 2.0.25 on the CI, the sysroot include dir is last:

set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES "/emsdk/upstream/emscripten/cache/sysroot/include/SDL;/emsdk/upstream/emscripten/cache/sysroot/include/compat;/emsdk/upstream/emscripten/cache/sysroot/include/c++/v1;/emsdk/upstream/lib/clang/13.0.0/include;/emsdk/upstream/emscripten/cache/sysroot/include")

from corrade.

mosra avatar mosra commented on June 3, 2024

Eh, in the end I actually did hit a similar problem, although in my case I had to add the non-cache include dir there: mosra/toolchains@6a9e082

Because FindZstd installed into the non-cache location (because otherwise it wouldn't be able to locate its libraries, because THE DAMN THING copies only contents of include/ but not lib/, EXCEPT FOR lib/cmake/, so I can't even put the CMake configs into lib/cmake/ but have to move them into share/cmake/ instead, as otherwise again it would be copied together with its includes but not libraries) otherwise added the non-cache include dir into the include path, resulting in an eventual error due to including the wrong doomed-to-fail <emscripten/version.h>.

I hate everything about this platform. Everything.

from corrade.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.