using GOA to port libraries

[Norman Feske]

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