[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 combinations: 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 toolchain.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. Jonathan