[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mingw-cross-env-list] Toolchain refactoring (was: MXE packages as A
Re: [Mingw-cross-env-list] Toolchain refactoring (was: MXE packages as APT)
Wed, 14 Oct 2015 02:27:10 +1100
> On 24 Sep 2015, at 07:08, Nagaev Boris <address@hidden> wrote:
> On Wed, Sep 23, 2015 at 2:58 PM, Tony Theodore <address@hidden> wrote:
>> 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.
Simplicity has it’s own virtue and it’s very hard to pre-empt use cases. I’ve
submitted a pull request that should help with our current issues.
> I prefer "phases" over "stages”.
“phases” are overkill at this stage;) But I agree, “phases” are more meaningful.
>> 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?
My thinking about “sections” was to control inclusion, and they would have
belonged to a “phase”. The “plugins” idea is a much better way to handle
>>  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)?
Phases don’t correspond to ordering so much as combinations of
build/host/target and various levels of bootstrapping. This will be clearer
when we introduce more compilers and runtimes.
|[Prev in Thread]
||[Next in Thread]|
- Re: [Mingw-cross-env-list] Toolchain refactoring (was: MXE packages as APT),
Tony Theodore <=