[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: jessie release goals



+++ Stephen Kitt [2013-05-07 14:38 +0200]:
> Hi Wookey,
> 
> On Tue, 7 May 2013 03:04:50 +0100, Wookey <wookey@wookware.org> wrote:
> > (just a decision to leave arch-independent headers in /usr/include and
> > move arch-dependent headers to /usr/include/triplet).
> 
> Doesn't this limit us to cross-compiling only across Debian architectures? If
> we go for a full /usr/include/triplet split (in the same way as for
> libraries)

Libraries are always different for different architectures. Only a
fairly small subset of headers is, so you could say we are doing
exactly the same thing for both libaries and headers: 
arch-indep stuff goes in /usr/{lib,include}
arch-dependent stuff goes in /usr/{lib,include}/triplet

But your point is taken.

The tradeoff is:
1) (Move _all_ headers to /usr/include/triplet)
 * Much duplication of installed headers
 * Only one system include dir, which fits current build-system 
     expectations
 
2) (Move only arch-dependent headers to /usr/include/triplet)
 * No duplication of headers
 * Two system include dirs, which may confuse/break some builds
 
In both cases things which manage to explictly look only in '/usr/include'
     may fail to build, but much more likely for 2. I have no idea how
much a problem this would be in practice.
'1)', above has been reasonably well tested in Ubuntu raring, and telling the
compiler to look in both dirs for system headers by default works
well, but there could be issues when given paths to subdirs.


> we could support cross-compiling to anything with the same
> structure - I'm thinking MinGW-w64 here of course, but I imagine it would
> apply to other targets too, some of which are supported in Debian already
> using the /usr/triplet/include directories.

The above issue is independent of the need for  dpkg-architecture to know
about an arch to use multiarch mechanism for cross-building to it. But
that's very easy to do (An easy way to add arches in a local config
file is something that's been mentioned before). Having mingw as an
arch is a good idea if it isn't already.

And you can still use a sysroot and non-multiarch ways of filling it
if you prefer. I haven't really experimented with mulitarch and
sysroot at the same time but SFAIK it should work. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


Reply to: