[PATCH] kernel/mingw64: add mingw64 kernel type

[Diorcet Yann]

Le 24/10/2012 19:30, Yann E. MORIN a écrit :
> Yann, All,
>
> On Wednesday 24 October 2012 Diorcet Yann wrote:
>> Le 24/10/12 00:59, Yann E. MORIN a écrit :
>>> Then, in scripts/build/kernel/mingw.sh:
> [--SNIP--]
>> Hum the 2 bitness process are very different. There is no way to make
>> merge configuration stuff and keep split scripts?
> There's no provision for that in crosstool-NG. However, it is possible
> with a bit of a hack. First, you'd need three files:
>      scripts/build/kernel/mingw.sh
>      scripts/build/kernel/mingw32.sh
>      scripts/build/kernel/mingw64.sh
>
> Then, in mingw.sh, you'd simply have this one line:
>     . "${CT_LIB_DIR}/scripts/build/kernel/mingw${CT_ARCH_BITNESS}.sh"
>
> And have the current code for each of mingw(32|64) in mingw\1.sh.
>
>> It avoid to have a big file with two things very different.
> That's not wrong, you get a point.
>
> However, I still would prefer that situation, where we have one big file
> with two almost completely different code-paths, rather than two different
> files.
>
> We've been down that road in the past with glibc and eglibc, with two
> completely different implementations, and it proved to be quite complex
> to merge back later on.
>
> I hope that it is inevitable that mingw32 and mingw64 end up being merged
> upstream, and I do not want we suffer again when that happens.
>
> And with the code-path I suggested for mingw.sh, we still get a clear
> separation between ming32 and mingw64, which is not too different from
> having two scripts.
>
> Anyway, if you decide not to do that yourself, that's fine. Provided the
> other points are addressed, I'll eventually merge your patchset as you'll
> provide it. Then, and although I can't promise anything, I'll eventually
> get to the point where I'll merge the two anyway.
>
> Do not get me wrong. I highly value your contribution (as I do for all
> others'). That's just that, as the maintainer, I want/need to lower the
> maintenance burden as much as I can, especially for features I do not use
> myself, to avoid the risk of eventually getting drowned (which is already
> starting to be somewhat an issue).
And why not simply make mingw-w64 generates gcc for 32bits 
(i686-w64-mingw32 target) ? (remove old mingw32 stuff?)
> Regards,
> Yann E. MORIN.
>



--
For unsubscribe information see http://sourceware.org/lists.html#faq