Re: jessie release goals
On Mon, May 13, 2013 at 07:26:15PM +0200, Stephen Kitt wrote:
> On Sat, 11 May 2013 11:39:28 +0200, Goswin von Brederlow <goswin-v-b@web.de>
> wrote:
> > On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote:
> > > 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).
> >
> > But it wouldn't. The target directory structure would be the same
> > across all builds. It would always be
> > /usr/include/[$(DEB_HOST_MULTIARCH)] and
> > /usr/lib/[$(DEB_HOST_MULTIARCH)].
> >
> > The effect of partial architecture is simply that not everything needs
> > to be build for that architecture and the partial architecture might
> > not be self hosting. E.g. we can cross build for mingw but we wouldn't
> > be including windows in Debian nor run a buildd on windows.
>
> Yes, but that's not the problem. Take the premise that the target directory
> structure is as described above, so most library development packages ship as
> many headers as possible in /usr/include. For now we'll assume all
> mingw-w64-...-dev headers are in /usr/include/...-w64-mingw32; but to use
> mingw-targeted libraries other than mingw-w64-...-dev (libgtk for example),
> the mingw toolchain needs to look in /usr/include as well.
Every compile has to look in /usr/inlclude/triplet and /usr/include/.
mingw is no special case there.
> This is all fine as long as libc6-dev is not installed (say perhaps with
> sbuild and cross-build-essential). But in a typical work environment,
> libc6-dev will be installed, and because we'll always be cross-compiling on
> the buildds, packages which need to build stuff for the host to run during
> the build (wine-gecko does this) need build-essential too, so libc6-dev
> headers end up in /usr/include and are picked up by the mingw toolchain.
Only architecture independent header are in /usr/include.
Now in the case of w32/w64 as architectures those headers must also be
suitable for windows or they are no longer architecture independent. I
guess that is the problem you see.
I don't see that anything changes for the layout. You just added a
rather strange arch which breaks the architecture independency of
libc6-dev stuff. Is that any different from building for a uclibc
system? I think you have the same problem there.
How much of libc6-dev and other libs are we talking about here?
Packages could also have:
foo-dev-common:all (or all foo-dev):
/usr/include/foo.h
foo-dev:w32:
/usr/include/w32/foo.h -> ../foo.h
foo-dev:w64:
/usr/include/w64/foo.h -> ../foo.h
Then mingw would only need to look there. This would be special casing
those archs. So not an ideal solution.
> Likewise for other -dev packages which may be available for the host
> architecture but not the target architecture. Imagine the confusion then for
> configure scripts!
Yes, that is a big problem. Luckily we have Build-Depends/Conflicts so
all the right packages are there and all the wrong packages are not.
For buildds that shouldn't be a problem.
Also any link test for libs will fail if the -dev is not installed for
the right arch.
> As far as I can see there are three solutions to this:
> * split headers completely
Possible without any toolchain changes. Just move the files in every
-dev package.
> * drop the idea of building mingw packages using the existing Debian
> packaging
I don't think mingw is overly special there. Cross-compiling,
esspecially for a different libc, will be verry similar.
> * add patches to all supported packages so that they build differently when
> targeting mingw (and any other partial architecture which can't
> share /usr/include)
* install w32/w64 packages in a sysroot, i.e. prefix every file on unpack.
Not sure how well that would work with maintainer scripts though. For
other cross-compiles one can use chroot but you probably don't want /
can't use that for w32/w64.
This could be done during build. Sort of like option 3. A small patch
to move debian/package/* to debian/package/usr/lib/mingw/ before
building the deb.
> Fedora went with the second solution; they have mingw-specific packages for
> everything they build targeting Windows. If we could build-depend on source
> packages (which has been mentioned elsewhere in this thread) this would be
> possible on Debian too, although it would be a bit of a chore for me (and
> whoever else wants to chip in). But I wouldn't want supporting a non-free
> operating system to become a chore for more Debian developers than necessary!
>
> (The aim of all the mingw work as far as Debian is concerned, apart from
> providing a nice mingw build environment, is to provide a wine-mono package,
> which needs a whole bunch of dependencies. wine-gecko is relatively easy to
> support because it's essentially Firefox, which ships all its build
> dependencies in its source archives.)
>
> Regards,
>
> Stephen
MfG
Goswin
Reply to: