[PATCH] kernel/mingw64: add mingw64 kernel type

[Diorcet Yann]

Le 24/10/12 00:59, Yann E. MORIN a écrit :
> Yann, All,
>
> On Wednesday 24 October 2012 Diorcet Yann wrote:
>> Le 23/10/2012 23:54, Yann E. MORIN a écrit :
>>> However, I have a few comments:
>> I have difficulty to understand all the stuff in crosstool-ng ... i have
>> only done a working patch (not a beautiful one).
> No problem, let's work together to get this in! :-)
>
>>>    1- I'd like to see how hard it would be to commonalise the mingw{32,64}
>>>       variants together, eg. take advantage on CT_ARCH_64 to decide what
>>>       mingw variant to build.
>>>       This would avoid duplicating code path for mingw.
>> Yes i tried, but the configuration stuff is still a mystery for me. I
>> don't see how to do it without lost 10h.
> A very simple way:
>
> First, in config/kernel/mingw.in, we could have something like:
>
> ---8<---
> # mingw32 config options
>
> ## depends on EXPERIMENTAL && ARCH_x86
> ##
> ## select MINGW    # Need to rename MINGW32 in kernel.in
> ##
> ## help Build a toolchain targeting systems running Windows as host
>
> choice
>      bool
>      prompt "API version"
>
> # Don't remove next line
> # CT_INSERT_VERSION_BELOW
> config WAPI_V_3_14
>      bool
>      depends on ARCH_32
>      prompt "3.14"
>
> config WAPI_V_2_0_7
>      bool
>      depends on ARCH_64
>      prompt "2.0.7"
>
> config WAPI_V_select
>      bool
>      prompt "Other version"
>
> endchoice
>
> config WAPI_VERSION
>      string
>      prompt "API version" if WAPI_V_select
> # Don't remove next line
> # CT_INSERT_VERSION_STRING_BELOW
>      default "3.14"  if WAPI_V_3_14
>      default "2.0.7" if WAPI_V_2_0_7
>      help
>        Enter the version number of the windows api files to use
> ---8<---
it seems nice indeed
>
> Then, in scripts/build/kernel/mingw.sh:
>
> ---8<---
> CT_DoKernelTupleValues() {
>      CT_TARGET_KERNEL="mingw32"
>      CT_TARGET_SYS=
> }
>
> do_kernel_ressources() {
>      # tarball, uri and src are variables declared by our caller
>      case "${CT_ARCH_BITNESS}" in
>          32) tarball="w32api-${CT_W32API_VERSION}-mingw32-src"
>              url="http://downloads.sourceforge.net/sourceforge/mingw"
>              src="${CT_SRC_DIR}/w32api-${CT_W32API_VERSION}-mingw32-src"
>              ;;
>          64) tarball= "mingw-w64-v${CT_W64API_VERSION}"
>              url="http://downloads.sourceforge.net/sourceforge/mingw-w64"
>              src=""${CT_SRC_DIR}/mingw-w64-v${CT_W64API_VERSION}/mingw-w64-headers"
>              ;;
>      esac
> }
>
> do_kernel_get() {
>      local tarball url src
>      do_kernel_ressources
>      CT_GetFile "${tarball}" "${url}"
> }
>
> do_kernel_extract() {
>      local tarball url src
>      do_kernel_ressources
>      CT_Extract "${tarball}"
> }
>
> # The two kernel are too different to share a single code path,
> # so we have a backend for each bitness variant.
> # Not-so-clean, but not-so-dirty either... :-/
> do_kernel() {
>      do_kernel_${CT_ARCH_BITNESS}_backend
> }
>
> do_kernel_32_backend() {
>      local tarball url src
>      do_kernel_ressources
>      "${src}/configure" --blabla...
>      # You get the idea... ;-)
> }
>
> do_kernel_64_backend() {
>      local tarball url src
>      do_kernel_ressources
>      "${src}/configure" --blabla...
>      # You get the idea... ;-)
> }
> ---8<---
Hum the 2 bitness process are very different. There is no way to make 
merge configuration stuff and keep split scripts?
It avoid to have a big file with two things very different.
> And a similar thing for the C library part.
>
> If at all possible, avoid using the _backend mechanism, if it is possible to
> have the same code-path, with only some locally-constrained conditionals on
> the bitness.
>
> [--SNIP--]
>>>> +CT_DoKernelTupleValues() {
>>>> +    CT_TARGET_KERNEL="mingw32"
>>> mingw_32_, really?
>> Yes really .. i was surprise too..;
>> see
>> http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler
>> all the configure use a target like this x86_64-w64-mingw32
> Nice pointer. You should add it to the help text in kernel/mingw.in
> to serve as a reference.
Ok
>
> [--SNIP--]
>>>> +do_libc_start_files() {
>>>> +    CT_DoStep INFO "Installing C library headers"
>>>> +
>>>> +    # It seems mingw is strangely set up to look into /mingw instead of
>>>> +    # /usr (notably when looking for the headers). This symlink is
>>>> +    # here to workaround this, and seems to be here to last... :-/
>>>> +    CT_DoExecLog ALL ln -sv "${CT_TARGET}" "${CT_SYSROOT_DIR}/mingw"
>>> I do not like the way the sysroot is organised... :-/
>>> I do not have enough bacgground in this 'kernel' to understand how
>>> everything should fit together. :-(
>> look
>> http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler
>>
>> it's quite simple... it correspond to the command "ln -s
>> /mypath/x86_64-w64-mingw32 /mypath/mingw"
> Yep, let's keep it that way.
>
>> PS: is there a way to restart the build from a step (and how know steps)?
> Yes:
>      $ ct-ng menuconfig
>          Paths and misc options  --->
>              [*] Debug crosstool-NG
>              [*]   Save intermediate steps
>              [*]     gzip saved states
>         (save and exit)
>      $ ct-ng build         (wait for it to finish or break)
>      $ ct-ng step_name     (restart only that step)
>      $ ct-ng +step_name    (restart from zero, stop before this step)
>      $ ct-ng sten_name+    (restart from that step, to the end)
>      $ ct-ng list-steps    (see list of steps)
>      $ ct-ng help          (see help ;-) )
Thanks
> Regards,
> Yann E. MORIN.
>


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