[cfe-dev] [RFC] Open sourcing and contributing TAPI back to the LLVM community

[Juergen Ributzka via cfe-dev]

Hi Paul,

My experience has shown the same when it comes to header files and I am not
claiming this is going to work out of the box for all library projects. It
usually requires some cleanup first and that is why the tool comes with a
verification mode to make sure the headers are the truth. Also keep in mind
that you don't have to parse all the headers, but only the small set that
get installed as part of the library API.

The tool does not read the linker script / export file, because they are
not necessarily the truth either and may have wildcards. In my view they
are just one way of managing exported symbols. Another way, which I
personally prefer, is to build with visibility hidden and annotate only the
API with visibility default. That makes the headers the single source of
what is API.

Cheers,
Juergen



On Fri, Sep 8, 2017 at 9:29 AM, Robinson, Paul <paul.robinson at sony.com>
wrote:

> > InstallAPI:
> > InstallAPI is a new build phase that generates the TBD file from header
> > files only. This allows a dependency of the library to build concurrently
> > even before the library has been built itself. This can be used to
> > increase parallelism in the build or larger projects or operating
> systems.
>
> My experience is that headers don't necessarily form the best source of
> truth about the API exported from a library.  If you follow the Windows
> model of marking exported APIs explicitly (declspec(dllexport) or
> something)
> then okay, but that's a Windows extension and not common in other systems.
> Linker scripts seem to be a more popular method; does the tool read linker
> scripts to form the content of a TBD file?
> Otherwise I'm not seeing a generic improvement in build parallelism.
> --paulr
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170908/3d6eae57/attachment.html>