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

Re: [pkg-wine-party] [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)

[CC ing Marcin]

On 23.11.2010 12:49, Dmitrijs Ledkovs wrote:
On 23 November 2010 12:17, Jonathan Nieder<jrnieder@gmail.com>  wrote:
Hi again,

[out of order for convenience]
Dmitrijs Ledkovs wrote:

=) can you sponsor our work in the future?

Only if I become DD.  I have not applied yet, so you will probably
need someone else.

That said, my experience has been that useful, policy-compliant
patches and packages tend to get integrated.  Maybe one of the
many wine-using DDs will pick it up once this works well.

mingw-w64 do all they work upstream. All patches that were created
mingw-w64 project are applied directly to binutils and gcc head.

That's great.  One possibility in the long run might be to package
this as part of the usual gcc and binutils packages, then.

please no. Adding more packages and complexity to the native gcc and binutils builds is a no-go.

I've tried it. Current debian-gcc packaging is generating
debian/control using m4 and it assembles 3 possible source packages:
gcc, gnat and gcj. Gnat and gcj build-depend on gcc-source package.

debian-gcc is a bit specific to the native libc based toolchains and
cross-toolchains using libc. I didn't manage to find an easy place to
plugin mingw-w64 bootstrap into that packaging.

You might want to have a look at Marcin's cross-build packages, using the gcc-, binutils- and eglibc- source packages. These may be currently test for the arm-linux target only, but should be fixable for mingw too.

And I would love to build the spu cross-toolchain the same way (using newlib instead of glibc).

In the past people have proposed additional packages like gcc-mips
depending at build time on the gcc-source binary package.  This way,
the archive would only need two copies (the .orig.tar.gz and the .deb)
of the gcc source, and variants building separately could reuse that.

imo the biggest advantage for such packaging is that both the native and cross toolchain is based on the same source and patches.

The problem with that it required separate work to follow the GPL.
Normally the archive software guarantees that (1) the precise source
package used to build each binary package is available and (2) the
build-time dependencies for packages in "main" are available in some
version from the Debian archive.  So after building gcc-mips,
gcc-source could be updated, and the result would be that gcc-mips
binaries were available for download but the exact corresponding
source would not be.  Avoiding this required some manual configuration
and there were some thoughts about how to make it automatic.

this is already guaranteed by the gcj and gnat builds by only relying on the tarball in the gcc-4.x-source package.

ok. I was playing around with this. My current plan is to try out:
generating debian/control from debian/control.subpackage*.in files
using sed magic and makefile if statements =) with following

1) binutils
2) gcc-bootstrap
3) mingw-w64
3) gcc-bootstrap (skip) - mingw-w64 - gcc-full
4) complete toolchain in one go =)

And generate appropriate debian/control in each case. Our
debian/changelog might go haywire though.....

About source and binary package versions. Source packages will use
sequential release numbers, while at build time binary packages will
get appropriate binary version which matches corresponding versions of
the *-source packages used during build. I don't think this is policy
compliant but doesn't gcc-defaults do exactly that?

I think brief mingw-w64-specific manpages would be ideal.

most of the manpages are for gcc and binutils executable. And they are
the same as in gcc-doc except that they are prefixed with target
tripplet and generate / work against PE object files. These docs are
under non-DFSG free license.

mingw-w64-specific manpages would be nice, but there aren't written
any yet detailing what is special or how to work with mingw-w64

This isn't a showstopper, just something nice to have.  (i.e.,
imho you should feel free to ignore lintian about this)

Thanks for the clarifications.

Reply to: