Is it possible to tell cmake that the toolchain will generate multiple files for executables?
I’m thinking more specifically about emscripten which (might, depending on compile flags) generate both .js and .wasm files for a single target.
Right now the toolchain file only sets the .js suffix here.
The impact I know of, caused by the .wasm file not being known by cmake are:
clean targetinstall(TARGETS )
It seems like some logic for Windows the dll/lib split may need to happen for Emscripten as well. @brad.king
While the Windows dll/lib split is also a case of multiple files associated with an executable target, their semantic meaning is different than emscripten’s .{js,wasm} pair, IIUC.
Similar logic would be needed to support the latter case.
Which file is used to actually run the executable (possibly through CMAKE_CROSSCOMPILING_EMULATOR)? That should be considered the primary output artifact. We’d need some name/concept to describe the role of the second artifact.
Which file is used to actually run the executable (possibly through
CMAKE_CROSSCOMPILING_EMULATOR)?
The .js file is used to load the .wasm for bootstrapping, it acts as a launcher.
But it is actually possible to ask emscripten to generate only the .js (if you don’t want webassembly support), .wasm if you don’t care about the small .js wrapper, and even a combination of html+js+wasm if you chose to use the default .html template.
Those are not the defaults of the toolchain however, but can be triggered either using compile options or changing the target file extension (ie, change the SUFFIX property).
As for CMAKE_CROSSCOMPILING_EMULATOR, it seems node.js was chosen by the maintainers, and uses .js files.
In the end, the .wasm file is kind of a library that you can run through the .js file, but is not mandatory if you don’t target web assembly.
I think it should be seen as a shared library that you can’t link (though I heard that there is now experimental support for shared libraries…).
Thanks for explaining. It sounds like the .wasm file can be treated as a resource associated with the .js executable. This is similar to the RESOURCE target property used on macOS for additional App bundle resources. However, one distinction is that the RESOURCE property is just for additional files provided by the project. The .wasm file is generated as an additional output from the linker.
Since the .wasm file is associated with the toolchain settings rather than a project, I think it would make sense to define an abstraction for additional linker-generated artifacts that can be configured by the Platform/* and/or Compiler/* information modules. The generators would then know about the extra file and could include them in the list of link rule outputs, installation rules, etc.
The split debug symbols files that some split off the executable in POST_BUILD would also fit into this. Especially if CMake gains built-in support for this one day.
Should I open an issue/feature request on gitlab for this ?
@hsattler since debuginfo is a general cross-platform concept I think it would be better to model its artifacts explicitly. We have CMake Issue 20256 open for that already.
@Lectem yes, please open an issue to track the emscripten case specifically, and mention the issue number back here for completeness.