-
Notifications
You must be signed in to change notification settings - Fork 10
Open
Labels
Description
Traditionally bake is mostly used for building static, cross, embedded, cish stuff. The need for shared libraries did not exist. Producing a shared lib with bake needs the following:
ExecutableConfig default {
ArtifactName "libblah.so"
[...]
DefaultToolchain {
Linker {
Flags add: "--shared"
}
}
}
This add the --shared (which only works for gcc/clang) to the linker invocation. bake thinks it builds binary but instead produces a shared object. Why not using LibraryConfig? LibraryConfig doesn't allow to overwrite the Linker. bake hardcodes the flags passed to the Archivier so adapting a LibraryConfig is not possible.
Anyway - the above hack isn't sophisticated because
- The toolchain can't be inherited from a project depending on this lib
- Linking against the shared artefact requires (nasty) custom steps like fiddling around with the output directories in the project that depends on the lib (and hardcoding the artefact name).
- The artefact name must be manually specified and might not reflect the target platform (dylib, so....).
Getting towards shared libs would mean:
- Extending the meta model to flag
LibraryConfigsassharedordynamic - Add Linker definitions in the toolchain specifications - probably a command and flags
- Probably something more
The top motivation point for shared lib support within bake is the need for shared libs when doing JNI.