Am 28.06.2014 19:44, schrieb Osamu Aoki: > Hi, > > The path for the arch dependent header file seems to have several options. > > 1) /usr/include/<multiarch>/*.h > 2) /usr/include/<multiarch>/<packagename>/*.h > 3) /usr/lib/<multiarch>/<packagename>/include/*.h > > I would like to know rationale for each choice, especially between 2 and 3.
1) has the advantage that it is found in the standard include path. 3) is a cheap work around for packages installing everything into a common prefix and then either providing symlinks in other places or forcing users to rely on pkg-config or other methods to find files. You are missing 1b) /usr/include/<packagename>/*.h There should almost be no issues for packages putting header files directly in /usr/include or /usr/include/<multiarch>. Yes, there are some dumb tests checking for the existence of files in a certain path which will break. Packages installing header files in /usr/include/<packagename> usually need a knowledge of the include path, and you'll break things just moving all header files or a part of it to /usr/include/<multiarch>/<packagename>, because depending packages expect that only one include path is sufficient. The solution here is to use a fake header in /usr/include/<packagename> which includes the appropriate header in /usr/include/<multiarch>/<packagename>. python2.7's and python3.4's pyconfig.h file is such an example. But even here you find configure checks to grep pyconfig.h for certain features which break which such kind of setup ... and of course it needs updates for new architectures. > I am sure they all are functioning choice but intriguing to see choice 3. > > (I was looking for the typedef of gsize in gobject header files in > /usr/include/glib-2.0. It tool me time to find it in > /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h) this doesn't seem to conform to the FHS, and I assume a FHS conformant packaging wouldn't make things worse. > As I look around on my system, I observe followings > > For 1, *.h are: > expat_config.h > ffi.h > ffitarget.h one of them can live in /usr/include, however I personally prefer to install header files in one location. > fpu_control.h > gmp.h this is an example where the upstream header was patched to co-install on 32/64 bit systems not knowing about multiarch. > ieee754.h > lua5.1-deb-multiarch.h > lua5.2-deb-multiarch.h > zconf.h > > For 2, <packagename> are > python3.3m see above for the explanation for python. > openssl > ruby-2.0.0 > c++ this is in the standard c++ include path, so it doesn't need any special configury. > ... > > For 3, <packagename> are: > glib-2.0 > gtk-2.0 > gtk-3.0 > dbus-1.0 (dbus/dbus-arch-deps.h as *.h) what a surprise ... I assume many upstream developers are working for distros not using multiarch. Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b5cbce.8050...@debian.org
