Thomas Moulard <thomas.moul...@gmail.com> writes: > On Tue, May 14, 2013 at 9:56 AM, Russ Allbery <r...@debian.org> wrote: >> Thomas Moulard <thomas.moul...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878v3gq0rc....@windlord.stanford.edu