Issue with liburiparser.a in Bleeding for Emscripten

[ofTheo]

I was trying out the bleeding libs for the web examples and they all had linking issues with this file: wasm-ld: error: unknown file type: /src/libs/uriparser/lib/emscripten/liburiparser.a(UriFile.c.o)

See: https://github.com/openframeworks/openFrameworks/actions/runs/7283340356/job/19847062682#step:6:2580

The only thing I can think to try is switching back to using emconfigure: https://github.com/openframeworks/apothecary/compare/master...bleeding#diff-275704f1663ce1ead132ed11662b9d94034354d538cbd0ecd85df9eb98e21514R209

[danoli3]

Ah yes this makes sense now, so one of the main things emscripten does differently is the code is all execution code, so just need to make sure the cmakelists contain add_executable() with the same sources in that.

in the cmake emscripten we are calling it actually overloads and library commands to build the correct systems. However we just need to just like when building for libraries, static or dynamic, just also make sure to build for execution.

This can be applied with cmakelist modification to uriparser like so:

if(EMSCRIPTEN)
    set(EMSCRIPTEN_CORE_SOURCES
        ${API_HEADER_FILES}
        ${LIBRARY_CODE_FILES}
    )

    add_executable(uriparser_wasm
         ${EMSCRIPTEN_CORE_SOURCES}
    )
    target_include_directories(uriparser_wasm PRIVATE
        ${CMAKE_CURRENT_SOURCE_DIR}/include
        ${CMAKE_CURRENT_BINARY_DIR}  # for UriConfig.h
    )
endif()

or just call URIPARSER_BUILD_TOOLS=ON (however will be bloated with their extra tools might not need).

• removed side module thing

this creates wasms

[danoli3]

I'll split the cmake emscripten in bleeding into two with the default emmake system with latest libraries until we can figure out cmake vars to get this over the line

[danoli3]

https://stunlock.gg/posts/emscripten_with_cmake/ Here is a breakdown of compiling, linking correctly and extra settings with CMake emscripten. I'll have a go today

[danoli3]

Okay, got my eyes back, lets see what we can do here

[danoli3]

More of an issue now since nightly added this to next build target again

[danoli3]

This is fixed