Hi Pirmin,
I have now a first version of Goa that supports creation of libraries.
>
> [...]
>
> [1] https://github.com/trimpim/goa/tree/library_support
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_rel.ld
Cheers
Norman
--
Dr.-Ing. Norman Feske
Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
_______________________________________________
Genode users mailing list
[email protected]
https://lists.genode.org/listinfo/users
