Install public headers in the standard path?

Discussion:

Chi-Hsuan Yen

2016-11-15 12:10:29 UTC

Hello libffi enthusiasts,

Currently libffi public headers are installed in
$PREFIX/lib/libffi-3.x.y/include. The only reliable approach to get
the include path is via pkg-config. There are some disadvantages:

1. pkg-config is tricky in terms of cross-compilation. To cross-build
libffi clients, PKG_CONFIG_LIBDIR, PKG_CONFIG_SYSROOT_DIR,
PKG_CONFIG_ALLOW_SYSTEM_{CFLAGS,LIBS} may be involved to make it
working

2. pkg-config does not come with macOS. Recently CPython is seeking
for chances to drop bundled libffi copy. [1] However, CPython core
developers are against including additional tools other than
XCode/Command Line Tools in CPython build time requirements

There are some more discussions here:
https://github.com/libffi/libffi/issues/258

As a result, I suggest to move header files to conventional
$PREFIX/include, so that libffi clients can have simpler build
systems.

Here's my implementation: https://github.com/libffi/libffi/pull/288

Any ideas?

Best,

Yen, Chi-Hsuan

[1] http://bugs.python.org/issue28491

Anthony Green

2017-01-05 23:53:15 UTC

Permalink

Thanks for your patch.

If you can believe it, installing certain headers under /usr/lib was a
thing back in the mid/late 90s (gnome, or gtk, or similar did this as
well). libffi headers are modified at configure time, and the
thinking back then was that the contents of /usr/include should not
vary based on configuration changes (or even on per-host basis).
Also, using pkg-config made it easy to install multiple versions of
libffi as the ABI hadn't settled down yet.

A few years ago I sat down to rewrite the headers to depend solely on
compiler-defined macros, but got lost in the maze of Power
alternatives. Every other port was fairly straight forward - but
Power was a mess.

I'm OK with moving the headers to /usr/include now, although it would
have been nice to remove the configure-time dependencies from them
first.

AG

Post by Chi-Hsuan Yen
Hello libffi enthusiasts,
Currently libffi public headers are installed in
$PREFIX/lib/libffi-3.x.y/include. The only reliable approach to get
1. pkg-config is tricky in terms of cross-compilation. To cross-build
libffi clients, PKG_CONFIG_LIBDIR, PKG_CONFIG_SYSROOT_DIR,
PKG_CONFIG_ALLOW_SYSTEM_{CFLAGS,LIBS} may be involved to make it
working
2. pkg-config does not come with macOS. Recently CPython is seeking
for chances to drop bundled libffi copy. [1] However, CPython core
developers are against including additional tools other than
XCode/Command Line Tools in CPython build time requirements
https://github.com/libffi/libffi/issues/258
As a result, I suggest to move header files to conventional
$PREFIX/include, so that libffi clients can have simpler build
systems.
Here's my implementation: https://github.com/libffi/libffi/pull/288
Any ideas?
Best,
Yen, Chi-Hsuan
[1] http://bugs.python.org/issue28491

Chi-Hsuan Yen

2017-01-06 15:16:36 UTC

Permalink

Post by Anthony Green
Thanks for your patch.
If you can believe it, installing certain headers under /usr/lib was a
thing back in the mid/late 90s (gnome, or gtk, or similar did this as
well). libffi headers are modified at configure time, and the
thinking back then was that the contents of /usr/include should not
vary based on configuration changes (or even on per-host basis).
Also, using pkg-config made it easy to install multiple versions of
libffi as the ABI hadn't settled down yet.

Thanks for clarification. The original decision looks much reasonable now!

Post by Anthony Green
A few years ago I sat down to rewrite the headers to depend solely on
compiler-defined macros, but got lost in the maze of Power
alternatives. Every other port was fairly straight forward - but
Power was a mess.
I'm OK with moving the headers to /usr/include now, although it would
have been nice to remove the configure-time dependencies from them
first.

Did you mean eliminating the process of ffi.h.in -> ffi.h? I guess it
can be resolved by distributing fficonfig.h as well. Lots of
autotools-based projects do similar. For example, CPython distributes
/usr/include/python3.6m/pyconfig.h.

Post by Anthony Green
AG