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

[Nagaev Boris]

On Wed, Sep 23, 2015 at 2:58 PM, Tony Theodore <address@hidden> wrote:
> 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.
>

Maybe it is a good point to introduce clang-based targets?
Some work is already done here:
https://github.com/tpoechtrager/wclang/issues/16
https://github.com/tpoechtrager/wclang/issues/7
https://github.com/mxe/mxe/issues/558

-- 


Best regards,
Boris Nagaev