Hi Dick
That looks promising. I would like very much to see Python move to CMake
in the future.
It is always a pleasure to build software using CMake.
Especially you can easily choose to build it using the excellent MinGW64.
However I decided to use a ready-to-use python distro, WinPython, for
2013/6/15 dw limegreenso...@yahoo.com:
My responses:
- While I don't really see the benefit, I'm ok with putting the inline
implementations in their own .h file. And it's going to feel odd
putting an include at the *bottom* of a file.
Well, I see advantage exactly in the point of having the
This issue was raised on the sf forum:
http://sourceforge.net/p/mingw-w64/discussion/723797/thread/cd8a855f
but I very much prefer to use the mailing list.
The problem: marking a class as dllexport prevents the inlining of its
class methods. I guess the same applies to inline functions. This
we don't need to maintain implementation at two places, if we do
things right.
Are you talking about something like what I did with intrin-mac.h? While
that allows us to (mostly) write it once, you still need to have it in
two places (and test both). Or did you mean something else? If
2013/6/15 dw limegreenso...@yahoo.com:
we don't need to maintain implementation at two places, if we do
things right.
Are you talking about something like what I did with intrin-mac.h? While
that allows us to (mostly) write it once, you still need to have it in
two places (and test both).
Hi,
first thanks for the heads-up. Pretty interesting finding.
2013/6/15 Óscar Fuentes o...@wanadoo.es:
This issue was raised on the sf forum:
http://sourceforge.net/p/mingw-w64/discussion/723797/thread/cd8a855f
but I very much prefer to use the mailing list.
The problem: marking a class
