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

[Dmitrijs Ledkovs]

On 10 December 2010 21:29, Matthias Klose <doko at debian.org> wrote:
> [CC ing Marcin]
>
> On 23.11.2010 12:49, Dmitrijs Ledkovs wrote:
>>
>> On 23 November 2010 12:17, Jonathan Nieder<jrnieder at 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
>>
>>
>
>