On Wed, 8 May 2013 03:57:20 +0100, Wookey <wookey@wookware.org> wrote:
> +++ Wookey [2013-05-07 22:31 +0100]:
>
> [right. 3rd attempt at getting this email to make sense. reposting the
> whole thing this time, hopefully with no remaining howlers]
>
> +++ 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. This is worthy of discussion to check we
> have at least vague consensus
>
> 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
* Incorrect builds fail faster than with (2) since there's nothing
in /usr/include
> 2) (Move only arch-dependent headers to /usr/include/triplet)
> * No duplication of headers
> * Two system include dirs, which may confuse/break some builds
> * Relatively little change from status quo
* Confused builds may seem to build correctly using the wrong headers (not
an issue with the base Debian use-case but bear with me...)
> In both cases things which manage to explictly look only in '/usr/include'
> may fail to build, (certainly in case 1, possibly in case 2). I have
> no idea how much of a problem this would be in practice.
>
> '2)', 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, e.g. if giving a path to a subdir
> of a system header(?).
>
> I'd be interested to hear of problems building against multiarched
> -dev packages with moved headers. Are there any significant ones?
Not that I know of...
But my main point is that all this assumes a level of uniformity in the
target architectures. So if we're building packages for Debian or Ubuntu,
just for different ABIs (mostly different hardware), everything works fine.
Throw non-Debian architectures (which could be partial architectures) into the
mix and things change drastically.
Let me explain where I'm coming from... With MinGW-w64, we have a set of
compilers, headers and libraries which allow building software targeting
native Windows, without Cygwin or much in the way of wrappers at all. This is
definitely non-POSIX and not much like Debian; but I imagine similar problems
crop up when targeting a different libc. Despite the differences, and thanks
to a lot of work by upstream developers, a lot of the libraries in Debian
build fine when targeting Windows, and most of the time the only change
required is to pass the correct target triplet to the configure script. This
makes it sorely tempting to add mingw (i386, amd64 and arm as Dmitrijs
mentions) as partial architectures in Debian and use all the existing
packaging as much as possible to provide at least -dev packages and DLLs for
as many libraries as possible; this would greatly simplify the lives of
people working on building stuff for Windows (currently they basically have
to produce Makefiles which build all their dependencies - and then you end up
with things like the Firefox source packages which include all their
dependencies on all platforms).
The big issue which crops up then isn't so much the directory structure's
impact on the build process, but rather its impact on the packaging process.
If the target directory structure depends on whether we're building for a
full Debian architecture or for a partial architecture or just some
cross-compiler target, that means ad-hoc changes in the packaging for the
various cases and that much more friction (see for example
http://bugs.debian.org/671437 - although in zlib's case packaging changes are
necessary to build for Windows).
I know (2) is well-tested, and it reduces duplication drastically. Does this
outweigh being able to use multiarch and Debian's existing packaging work as
a generic means of supporting cross-compilers?
> > 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 header-layout issue is independent of the need for dpkg-architecture to
> know about an arch to use multiarch mechanisms 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 multiarch and
> sysroot at the same time but SFAICS it should work.
Indeed, but when I first saw multiarch I couldn't help but think this was a
really nice way to support cross-compilation too; at the time I was told it
was too early to consider that, it would appear now is the right time before
things become set in stone.
Unless I'm mistaken, if we go down the (2) route we could still have a mingw
(partial) architecture, but every single package we'd want to build on it
would need to handle it specifically...
Regards,
Stephen
Attachment:
signature.asc
Description: PGP signature