Hi,
My problem was to have mingw-cross-env work with mingw-w64. To do
this, there is a need for a "mingw-cross-env" framework that can
handle both the mingw and the mingw-w64 runtimes. Following this, Tony
linked to older threads on this subject :
The start of the latest thread was back in November [1], but you can
search the archives [2] for more background. I've pushed the changeset
to bitbucket [3] for easy viewing.
The three main issues were [4]:
1. Overhead of multiple runtimes (supporting both mingw.org and
mingw-w64)
2. Mingw-w64's (apparent) preference for multi-lib configuration
3. Simplicity and coherence of design in mingw-cross-env
I subsequently discovered that 2 was a following-the-docs-too-closely
issue, and this could potentially make 1 a non-issue, but there's
still the simplicity which eludes me.
Cheers,
Tony
[1]
http://lists.nongnu.org/archive/html/mingw-cross-env-list/2011-11/msg00109.html
[2]
http://lists.nongnu.org/archive/cgi-bin/namazu.cgi?query=mingw-w64&submit=Search%21&idxname=mingw-cross-env-list&max=20&result=normal&sort=date%3Aearly
[3]
https://bitbucket.org/tonyt/mce-multi-target/changesets/tip/2127%3Atip
[4]
http://lists.nongnu.org/archive/html/mingw-cross-env-list/2011-11/msg00130.html
Tony identified 3 points (see above). I spent quite some time thinking
all this.
1 : "overhead of multiple runtimes, supporting both mingw.org and
mingw-w64". It is true that including mingw-w64 support in
mingw-cross-env will increase the work! No way to find a smart
solution that solves this. However, the community will also get
bigger! And ultimately, you can hope that the mingw runtime will get
deprecated, and then focus on mingw-w64.
2: "mingw-w64 preference for multilib". Actually, this is not really
true. Mingw-w64 proposes 2 way of building it :
- either you do "multilib"
- or you compile first for 64 bits, then for 32 bits.
But the community prefer using the second solution. It is easier to
handle (I discussed this point on the mingw-w64 forum) when building
tools on top of gcc.
3 : simplicity and coherence of design in mingw-cross-env
That is the big point. The solution that Tony created was modifying
every *.mk files to include support for both mingw and mingw-w64. I
propose something different.
- two parallel source directories, instead of one : mingw with its
*.mk files, and mingw-w64 with its own *.mk files.
- three possible targets : i686-pc-mingw32 (works with mingw) ,
i686-w64-mingw32 (works with mingw-w64, for 32 bits),
x86_64-w64-mingw32 (works with mingw-w64, for 64 bits)
- compatible builds in same directory : instead of changing name, for
example "i686-pc-mingw32_zlib", the files have the form
"i686-pc-mingw32/zlib"
- small changes to the Makefile
- fully compatible with the actual work on mingw
The changes I made :
- slightly modified Makefile, with a "SRC" parameter added (for either
mingw or mingw-w64 source directory)
- move "src/*.mk" files to "src/mingw/*.mk" files
- the process changes log files to produce, instead of "log/*" :
log/i686-pc-mingw32/*
log/i686-w64-mingw32/*
log/x86_64-w64-mingw32/*
- the process changes "usr/installed/*" files to :
usr/installed/i686-pc-mingw32/*
usr/installed/i686-w64-mingw32/*
usr/installed/x86_64-w64-mingw32/*
If you think my proposal is good, and if the branch is updated, then
it will be easy to start to update the parallel "mingw-w64" branch in
this framework, which will consist in adding a src/mingw-w64 directory
with src/mingw-w64/*.mk files.
I have an updated branch of mingw-cross-env that adapts it for
multi-target purposes.
How can I submit it ? I tried "hg export -g", but it says : "abort:
export requires at least one changeset". If I do "hg status", I can
see all my changes.
I don't know well hg, I am more used to svn.
Best Regards,
William
mingw.patch