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.

I like the idea.

> 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.

I prefer "phases" over "stages".

>
> 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.

My understanding of this separation between phases and sections is not
ideal. Do sections belong to phases? I.e. one phase has one or more
sections? Does a package belong to one or many phases/sections?

> 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 corresponds to host/build/target (another order)?

-- 


Best regards,
Boris Nagaev