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

[Diorcet Yann <diorcet dot yann at gmail dot com>]

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