On Wed, 08 Aug 2012 11:09:15 +0200, Remi Collet wrote:
> It's a bug in the same way it would be a bug if the headers
were stored
> below %_bindir, %_mandir, %_sysconfdir or dirs other than %_includedir.
I mostly agree, but...
Where arch specific header should go ?
%{_includedir}/something-target-cpu-dependent/
and have $(pkg-config --cflags) return that directory. With a versioned
topdir, one example would be:
/usr/include/libname-1.0/${ARCH}/libname/*.h
$ pkg-config --cflags libname-1.0
-I/usr/include/libname-1.0/${ARCH}
#include <libname/….h>
It could even be the upstream installer doing that, with arch-dependent
conditionals in platform-independent headers including the arch-specific
bits from subdirs.
/usr/include/libname/*.h
-> /usr/include/libname/${ARCH1}/*.h
-> /usr/include/libname/${ARCH2}/*.h
And if it weren't a versioned topdir, you could even access the header
files without extending search path list, since /usr/include is a default
search path whereas %_libdir is not.
$ find /usr/lib64 -name \*.h | wc -l
393
most are perl and qt headers,
but some gnome package also put their header here.
Qt also stores (or used to store) executables somewhere below %_libdir,
using it as some sort of home/root dir. Not a suitable counter-example
to prove anything other than that some more headers are misplaced.
Currently we use some workaround (see mysql or libzip)
/usr/include/mysql/my_config.h
/usr/include/zipconf.h
(libzip upstream also use %{_libdir} for zipconf.h)
So, I think, %{_libdir}/foo/include is not a so bad solution.
For multiarch, it's a work-around only, a lazy one, as %_libdir is a quick
way to get a directory that differs by arch.
--
Fedora release 17 (Beefy Miracle) - Linux 3.5.0-2.fc17.x86_64
loadavg: 0.00 0.09 0.39