Gentoo Archives: gentoo-dev

From: Marty Plummer <netz.kernel@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] mingw-w64 crossdev prefix?
Date: Thu, 18 May 2017 04:50:09
Message-Id: 20170518045240.bezemjns376zeovp@tha-monstah.mydomain
In Reply to: Re: [gentoo-dev] mingw-w64 crossdev prefix? by Ian Stakenvicius
1 On Thu, May 18, 2017 at 12:42:09AM -0400, Ian Stakenvicius wrote:
2 > On 18/05/17 12:08 AM, Marty Plummer wrote:
3 > > On Thu, May 18, 2017 at 06:46:24AM +0300, Alon Bar-Lev wrote:
4 > >> Hi,
5 > >> You can emerge crossdev and then run crossdev -t x86_64-w64-mingw32 or
6 > >> crossdev -t i686-w64-mingw32
7 > >> Alon
8 > >>
9 > > I'm aware of that, using it. Its simply the fact that its fairly broken
10 > > for mingw-w64, and requires quite a lot of hackage to get going.
11 > >
12 > > What I'm suggesting is the creation of a profile that should handle this
13 > > sort of thing for you semi-automatically. Something like the
14 > > prefix/windows, but meant more for toolchains. it seems that beber's
15 > > portage tree at git.meleeweb.net/gentoo/portage.git already has a setup
16 > > similar to what I envision already.
17 > >
18 >
19 > There isn't a whole lot that's broken about it actually -- the main
20 > issue is that the default 'embedded' profile doesn't allow all of the
21 > variable overrides in it that are necessary for the crossdev to work
22 > properly. See bug http://bugs.gentoo.org/487310
23 >
24 > The crossdev that's created will provide all the necessary profile
25 > overrides to allow you to emerge the things you want, and of course
26 > compile your own things as well. There's no need for a special prefix
27 > (or 'prefix/*' profile) in order to support this, IMO, once the
28 > embedded profile permits the overrides necessary to the ARCH, ELIBC,
29 > and KERNEL variables that the crossdev tool already sets.
30 >
31
32 There's also a host of packages that are pulled in by default which are
33 simply uneeded for this sort of setup, such as coreutils, sed, file,
34 debianutils which have to be manually package.provided away by end
35 users. I'm simply suggesting we should make this a bit more easy for
36 everyone involved, as it could ease use and possibly cut down on
37 spurious bug reports if there was a standardized way of doing things.
38
39 This is a common enough use case that it should be handled upstream
40 imho. I'm more than willing to help in this matter, but I don't want to
41 be spitting into the wind if nothing will actually come of it.