Rant: So you want help?

[Kevin Krammer]

On Sunday, 2010-11-07, Thomas Friedrichsmeier wrote:
> On Sunday 07 November 2010, Kevin Krammer wrote:
> > So you end up having to build all dependencies with GCC if you want one
> > application to be built with GCC.
> 
> And vice versa.

Of course.

> > Maybe the things that are currently a problem for MSVC can be built with
> > a different compiler but one that is following the platform standard?
> > Intel's or Borland's maybe?
> 
> The problem will just shift, not go away. Consider your (external)
> dependency is built with MinGW. So building your application with the
> "platform standard" C++-ABI is the wrong thing to do, in this case.

I assumed that Windows had a platform C++ ABI like other OSes, defined by the 
OS vendor's C++ compiler. Reading Andrius' reply it doesn't seem there is.

Under that assumption it might have been possible to find a compiler that can 
build all dependencies.


> P.S.: But also, I think that supporting multiple compilers can hardly be
> considered a "solution" to the problem, either. It just splits up the set
> of breakages into two distinct sets: those that are broken with MSVC, and
> those that are broken with MinGW (three sets, if you count those that are
> broken with either compiler). Let the user choose: You want bug A or bug
> B?

I wasn't thinking about making an else/or decision, rather having KDE built 
with MSVC (again under the assumption that it would be defining the Windows 
C++ ABI) and build just applications that need a different compiler with a 
different but compatible one.

Since the assumption doesn't hold, there is little point in considering this 
an alternative.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20101107/cdbd49a0/attachment.sig