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

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/llvm-dev/attachments/20170908/3d6eae57/attachment.html>

I think it makes sense to have support for this input format in the tools.
Since the macOS SDK is slowly switching to this, having the tools work out
of the box is a nice feature.  It is rather convenient having a single
toolset be sufficient to provide infrastructure for all the targets.

Saleem

On Fri, Sep 8, 2017 at 10:32 AM, Juergen Ributzka via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> 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
>>
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171023/0405e3d8/attachment.html>

To belatedly second Juergen, yes I think the concept of TBD files is 
great, and not just useful to the specific XCode situation of 
proprietary libraries. For example the mapfiles[1] of Illumos are 
exactly analogous and used not because the libc of Illumos is closed 
source (it isn't) but rather to ensure comparability across Illumos 
versions. The libc (shared library) ABI of Illumos is the stable 
interface rather than the syscall ABI like Linux, so ensuring linkers 
see *only* see the export list at build time prevents the abstraction 
from leaking and unintended incompatibilities being utilized.

Beyond my general esteem for using export lists for hermetic builds, I'm 
working on automated native and cross builds for Darwin, and it would be 
a lot more convenient if this was part of LLVM.

So what happened to this? I searched TAPI on differential and didn't see 
anything.  Given the general need for something like a standardized 
export list to feed a linker instead of the shared library itself, and 
the utility of this specific format given its use by a major platform, I 
think it definitely should be upstreamed.

John

[1] 
https://github.com/joyent/illumos-joyent/blob/master/usr/src/lib/README.mapfiles

I'm also going to chime in here pretty late. I've been thinking about
proposing a tool (which I've been calling llvm-abitool) to do many of these
same things. I would be willing to contribute the ELF part of this tool and
get that up and running.

On Sat, Apr 7, 2018 at 9:12 PM John Ericson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> To belatedly second Juergen, yes I think the concept of TBD files is
> great, and not just useful to the specific XCode situation of
> proprietary libraries. For example the mapfiles[1] of Illumos are
> exactly analogous and used not because the libc of Illumos is closed
> source (it isn't) but rather to ensure comparability across Illumos
> versions. The libc (shared library) ABI of Illumos is the stable
> interface rather than the syscall ABI like Linux, so ensuring linkers
> see *only* see the export list at build time prevents the abstraction
> from leaking and unintended incompatibilities being utilized.
>
> Beyond my general esteem for using export lists for hermetic builds,
I'm
> working on automated native and cross builds for Darwin, and it would be
> a lot more convenient if this was part of LLVM.
>
> So what happened to this? I searched TAPI on differential and didn't
see
> anything.  Given the general need for something like a standardized
> export list to feed a linker instead of the shared library itself, and
> the utility of this specific format given its use by a major platform, I
> think it definitely should be upstreamed.
>
> John
>
> [1]
>
>
https://github.com/joyent/illumos-joyent/blob/master/usr/src/lib/README.mapfiles
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180409/21ffce44/attachment.html>