Re: Multiarch and architecture specific headers
Thomas Moulard <thomas.moulard@gmail.com> writes:
> On Tue, May 14, 2013 at 9:56 AM, Russ Allbery <rra@debian.org> wrote:
>> Thomas Moulard <thomas.moulard@gmail.com> writes:
>>> A package I maintain contains a configuration header (vpConfig.h)
>>> which differ depending on the architecture we are (here the
>>> dependencies are not the same on i386 and powerpc).
>>> So far, the only solution I can think of is moving this header into
>>> /usr/include/<triplet>
>>> and patching the .pc file accordingly.
>> There should be no need to modify the *.pc file. (Indeed, I think that
>> would be incorrect.) /usr/include/<triplet> is part of the default
>> search path for the compiler for exactly this purpose.
> Hum I see. However, the headers are located into include/visp/* and
> not include/*
> so still I think patching the .pc containing already
> -I/usr/include/visp to append
> -I/usr/include/`dpkg-architecture -qDEB_HOST_MULTIARCH` is necessary...
Oh, yes, indeed.
You may want to try to talk upstream out of that include style. It's
essentially always better to not have the -I flag and instead require that
programs using those headers use the full name of the header. In other
words, omit -I and modify programs to do:
#include <visp/header_name.h>
The whole point of putting the headers in the visp subdirectory is for
namespace management: it avoids problems if they conflict with some other
header name. You don't want to then go and undo the benefit of namespace
management with the -I flag so that you have to worry about conflicts with
other headers of the same name again!
About the only time when -I makes sense is if you're doing it for API
control or alternative API selection; in other words, you have (to pick an
example) apr-1.0 and apr-0.4, and you want to be able to build an
application against either one without changing the source code of the
application, or (more generally) you have two different implementations of
the same API and you want to be able to pick between them at compile time.
Based on the description of libvisp, it seems unlikely that either of
those apply to it. (It specifically says it's unique. :))
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: