2014-02-21 6:44 GMT+01:00 Stephen Kitt <[email protected]>:
> Hi Ingo,
>
> On Tue, 04 Feb 2014 21:40:28 +0100, Ingo Maindorfer <[email protected]
> >
> wrote:
> > how was the talk? Is there a way to get your talk online?
>
> I'm not really the right person to ask, but the audience seemed interested
> enough and I discovered a few more MinGW-w64 users. My slides are available
> on http://www.sk2.org/talks/ ; it was filmed so there should be a video at
> some point.
>
>
Hi Stephen,
If you don't mind I've got some comments and/or questions on the content of
your presentation. Some are just my opinion, feel free to ignore those ;-)
Apart from the usual
Debian-makes-everything-much-harder-but-maybe-that's-just-because-they-have-a-sh*tload-of-targets-to-support,
some specifics:
- CMake toolchain file: Arch has a mingw-w64-cmake package, which includes
toolchain files. This enables any CMake-based package to use a centralized
toolchain package, which reduces maintenance of all these packages. Worth
considering in my opinion ;-)
- "mingw-w64-dev" contains Pthreads" -> Why not split this off? It's not
100% necessary, although c++11 threads and also libgomp rely on this. It
would also make seperate updates possible, e.g. when a patch is available
for winpthreads, only that small part needs a rebuild, not the whole
crt/headers. Also, there are other additional MinGW-w64 libraries and tools
that you may consider adding to the packages.
- "mingw64" is a terrible name. Comparing it to mingw32 which is also
terrible just confuses everyone not familiar with what it's supposed to
mean. Why not just "mingw"? It's not like MinGW.org is still used by
Debian, or if it's ever going to support 64-bit without considering merging
with MinGW-w64 (these are all speculations, but hey, just look at the
timeline of both projects and the momentum gained by MinGW-w64 over
MinGW.org).
- slide 28.1: What do you mean by "How do we define the contents of
/usr/include"? That directory should never be searched by the
cross-compiler. Instead, it should search /usr/<target>/include, but on
multilib that might become more difficult. Note that I introduced a
non-multilib compiler for Arch, so that any libraries just install to
prefix=/usr/<target> and all is well, everything is found automagically, no
special configure options for every package required. That's also the main
reason for choosing such an approach.
- slide 29: isn't autotools support already in upstream sources? I'm not
sure about the config.guess and config.sub stuff though.
Anyways, cool presentation, and it's nice to see Debian trying to
accomodate MinGW-w64 cross-compilers better.
Cheers,
Ruben
Regards,
>
> Stephen
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
