Hi Pirmin,
I have now a first version of Goa that supports creation of libraries.
[...]
thank you for sharing your work, which looks very promising.
The following thoughts crossed my mind when looking through the commits of your branch.
- It is very good to see how you followed Goa's internal patterns, even down to the documentation. :)
Down the road, it would be good to avoid the code repetitions in 'extract_api_artifacts'. From cursory look, there seem to be many similarities with the existing 'extract_artifacts_from_build_dir' function. So it may be worth factoring out the reusable parts of the existing code into small utility functions as an intermediate commit.
- The ABI (in the form of the symbols file) should better not be implicitely created from the linked library. A manual curation step should remain part of the work flow. The (manual) invocation of the abi_symbols utility (e.g., disguised as a goa command) can possibly streamline this step (see below) but it should not transparent.
The main reason is that the symbol sizes are sometimes critical. A symbol file created via the abi_symbols tool from a 32-bit .lib.so file won't always work on 64-bit architectures. A secondary reason is that an ABI is sometimes only a subset of the symbols found in an .lib.so file. Removing symbol noise is good for keeping the ABI stable over time. The subset can be best carved out by manual inspection.
Hence, the symbols files should be handled as part of the Goa project, not generated automatically. To do so, we'd need a convention, e.g., hosting symbol files always in project-local files called 'symbols/<libname>' in the project directory. The name of the <libname> would correspond to the base name of the .lib.so file. With such a convention in place, Goa could aid the update/extraction of symbols via a command like:
goa extract-abi-symbols
This command would trigger the library build (to get hold of the .lib.so files), call the abi_symbols for the libraries, and thereby update the content of the symbols/ directory. This new version could then undergo human inspection before being commited into the project.
Note that this command would only be needed by the maintainer of the library (or library port), not the users of the Goa project who merely want to reproduce the build for using the library.
- I was surprised to find Genode's linker script [2] genode_rel.ld absent from your commit series. Do the resulting shared libraries actually work with Genode's dynamic linker? I wouldn't have expected that.
- Goa should not depend on the Genode source tree. The tools required by Goa should be hosted locally under Goa's share/goa/ directory. I consistently did that for the (parts of the) depot, ports, and gosh tools and would like to continue this path. In a distant future, I imagine that regular Goa users won't need to look at Genode's source tree at all, similar to how application developers on Linux don't need to look at the Linux kernel's source tree.
Now, looking again at your latest branch, I saw that you already applied this pattern. Very nice!
[2] https://github.com/genodelabs/genode/blob/master/repos/base/src/ld/genode_re...
Cheers Norman