On 10 December 2010 21:29, Matthias Klose <d...@debian.org> wrote: > [CC ing Marcin] > > On 23.11.2010 12:49, Dmitrijs Ledkovs wrote: >> >> On 23 November 2010 12:17, Jonathan Nieder<jrnie...@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. >
Ok, agreed. We will be using gcc-source and/or various DEB_STAGE API to debian/rules from gcc-source. >> 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. > Yeap, I did have a little chit-chat with Marcin about arm-toolchain-base package of his. I have forked it and started working on it. It does assume that there is a debian port of the target-arch. Starting an unofficial mingw-i386 and mingw-amd64 ports are probably the best thing, since the cross-toolchain package will be more streamlined with other cross-toolchain packages and it would be much easier to build all the dev packages and later install them with xdeb / apt-cross / dpkg-cross / *dpkg multiarch* > And I would love to build the spu cross-toolchain the same way (using newlib > instead of glibc). > Ok. -toolchain-base method is the current winner. I will work on providing a cross-toolchain using similar method. Thanks for looking into this =) >>> 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 >> >> > > -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=+1ggar9+b3swi6gplejw3jmq7fogqi==1s...@mail.gmail.com
