Multiarch and architecture specific headers

[Thomas Moulard]

Hello there,
I am looking for a solution to fix the following bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707754

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.

I saw that some packages are already putting headers in this directory
but I never
heard of this strategy on the Debian wiki.

Is this considered good practice? Is there another solution to deal
with this bug?

Thanks,
--
Thomas Moulard（ムラー　トマ）
CNRS-AIST JRL (Joint Robotics Laboratory), UMI3218/CRT, Tsukuba, Japan
http://thomas.moulard.net | GPG Key Id: 516FC68F31496D58
Add me on LinkedIn: http://www.linkedin.com/in/moulard


--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CADNCw2YvXwB+NboCd_YWPPHk...@mail.gmail.com

[Boris Pek]

Hi Thomas,

> I am looking for a solution to fix the following bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707754
>
> 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.
>
> I saw that some packages are already putting headers in this directory
> but I never
> heard of this strategy on the Debian wiki.
>
> Is this considered good practice? Is there another solution to deal
> with this bug?

I think you are searching for these links:
http://wiki.debian.org/Multiarch/TheCaseForMultiarch
http://wiki.debian.org/Multiarch/LibraryPathOverview
https://wiki.ubuntu.com/MultiarchCross

Best wishes,
Boris

--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/14831413...@web11e.yandex.ru

[Russ Allbery]

Thomas Moulard <thomas....@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.

> I saw that some packages are already putting headers in this directory
> but I never heard of this strategy on the Debian wiki.

That's mostly because multiarch for -dev packages isn't really
well-documented yet. But I believe this is the right approach.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/87vc6me...@windlord.stanford.edu

[Thomas Moulard]

On Tue, May 14, 2013 at 9:56 AM, Russ Allbery <r...@debian.org> wrote:
> Thomas Moulard <thomas....@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...

>> I saw that some packages are already putting headers in this directory
>> but I never heard of this strategy on the Debian wiki.
>
> That's mostly because multiarch for -dev packages isn't really
> well-documented yet. But I believe this is the right approach.

Ok, then I will go with this. Thank you for your help and the links
toward the doc,
--
Thomas Moulard

--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CADNCw2bKrG3+mk4G7+biY1Z7...@mail.gmail.com

[Russ Allbery]

Thomas Moulard <thomas....@gmail.com> writes:
> On Tue, May 14, 2013 at 9:56 AM, Russ Allbery <r...@debian.org> wrote:
>> Thomas Moulard <thomas....@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-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/878v3gq...@windlord.stanford.edu

[Игорь Пашев]

2013/5/15 Thomas Moulard <thomas....@gmail.com>:

> 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...

AFAIK gcc searchs /usr/include/$(DEB_HOST_MULTIARCH) first.

--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/CALL-Q8xFN3oJZLa6Ta7mWTOy...@mail.gmail.com