[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Mingw-cross-env-list] Toolchain refactoring (was: MXE packages as APT)
From: |
Tony Theodore |
Subject: |
[Mingw-cross-env-list] Toolchain refactoring (was: MXE packages as APT) |
Date: |
Wed, 23 Sep 2015 21:58:06 +1000 |
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.
- [Mingw-cross-env-list] Toolchain refactoring (was: MXE packages as APT),
Tony Theodore <=