[Mingw-cross-env-list] Toolchain refactoring (was: MXE packages as APT)

[Tony Theodore]

Apologies for the belated reply.

> On 29 Jun 2015, at 03:10, Volker Grabsch <address@hidden> wrote:
> 
> Dear MXE Team,
> 
> Who knows more about the gcc-* and/or yasm packages?
> 
> Can we fix those duplicates directly in the recipes?

Not in an elegant way, it’s a holdover from introducing multiple targets 
without separating the native and cross build phases. Packages can only depend 
on other packages, not previous targets, so we have to create a fake linear 
ordering with the pseudo gcc-* packages. Yasm has no dependencies and doesn’t 
need the pseudo packages to prevent circularity, but it still builds the native 
component multiple times unnecessarily (as do gcc-* and pkgconf).

> Or, are there deeper issues we need to consider?

Ideally, the build should be broken into (at least) two stages - native and 
cross. This could be achieved by some rules in the Makefile so that 
$(MXE_TARGETS) depend on $(BUILD), removal of the pseudo packages and moving 
the build rules to the real packages. Call this “target” dependencies and it 
has the benefit of being simple. 

It also means we’d still have “fake" dependencies like binutils—>pkgconf and 
all cross packages depending on gcc. A minor nitpick I know, but these deps are 
really just manual ordering in the absence of a higher level dependency concept 
than “targets".

There are actually three phases (stages?) - native, toolchain, and cross [1]. 
I’d like to propose that we use those as a high level dependency ordering and 
assign a new $(PKG)_SECTIONS (not sure of the best name) to each package.

Yasm is interesting in this case as it exists in all three:
    native - build yasm assembler
    toolchain - create prefixed symlinks to isolate from any existing install
    cross - build libyasm

That may look like overkill, pkgconf and yasm will simply install symlinks, but 
it does provide a clear separation of concepts. Most packages won’t exist in 
all three and for the most part, we could simply infer that it’s a cross 
package if not explicitly stated.

The reason I’d like to keep stages/phases separate from sections is that 
sections allow finer control of what is included. It will provide great 
flexibility to do things like:

native-opt: optional native builds (say on OS X)
native:     native requirements gmp, mpc, mpfr etc. (maybe glib-genmarshall 
etc. down the track)
toolchain:  binutils, gcc, mingw-w64, pkgconf, yasm
cross:      most packages
cross-bin:  gdb wget
cross-opt:  other tools(mxe-exe?), licence conflicts(ffmpeg/openssl)?

So stages/phases to control ordering and sections(?) to control inclusion.

Thoughts?

Cheers,

Tony


[1] native/toolchain/cross roughly correspond to build/target/host in 
gcc/binutils terminology but I’m trying to stay away from that.