Re: [PATCH] kernel/mingw64: add mingw64 kernel type

["Yann E. MORIN" <yann dot morin dot 1998 at free dot fr>]

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

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

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.

[--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 ;-) )

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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