llvm dev - Jan 2013 - [LLVMdev] Using C++'11 language features in LLVM itself

>> Bah, they can install Mingw binaries.
> Sure! Actually, I wonder why people care about Visual Studio at all.
Basic MSVC linkage should work with Mingw.  Anything that doesn't work is
probably something that ultimately needs to be understood on the clang/llvm side
for the sake of clean integration.  IMO, a compatible & mature open source
Windows toolchain like Mingw that mostly works is a better apparatus for
understanding and fixing real technical integration problems (in LLVM and clang)
than a proprietary compiler.

Anyway, I thought the question here amounted to how to ensure that people can
make binaries of LLVM libraries and a working clang executable on Windows. 
Mingw can do that.  Or some enterprising person can just distribute a binary
distribution like has been done for years with Mingw.

Whether LLVM and clang can perfectly target Windows is a separate issue that
making LLVM & clang source code friendly to Visual Studio can't really
help with anyway.

Marcus

On Thu, Jan 10, 2013 at 5:46 PM, Daniels, Marcus G <mdaniels at
lanl.gov>wrote:
>
>
> >> Bah, they can install Mingw binaries.
>
> > Sure! Actually, I wonder why people care about Visual Studio at all.
>
> Basic MSVC linkage should work with Mingw.  Anything that doesn't work
is
> probably something that ultimately needs to be understood on the clang/llvm
> side for the sake of clean integration.  IMO, a compatible & mature
open
> source Windows toolchain like Mingw that mostly works is a better apparatus
> for understanding and fixing real technical integration problems (in LLVM
> and clang) than a proprietary compiler.
>
At the C level, yes.  At the C++ level, not really.

>
> Anyway, I thought the question here amounted to how to ensure that people
> can make binaries of LLVM libraries and a working clang executable on
> Windows.  Mingw can do that.  Or some enterprising person can just
> distribute a binary distribution like has been done for years with Mingw.
>
The problem is that LLVM is a C++ library.  You cannot build it with MinGW
and then consume the libraries with MSVC.  If you want (need?) to compile
your application with MSVC, then you have to build LLVM with MSVC too.

>
> Whether LLVM and clang can perfectly target Windows is a separate issue
> that making LLVM & clang source code friendly to Visual Studio
can't really
> help with anyway.
>
> Marcus
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130110/1dbb080d/attachment.html>

On Jan 10, 2013, at 3:57 PM, Justin Holewinski wrote:
> The problem is that LLVM is a C++ library.  You cannot build it with MinGW
and then consume the libraries with MSVC.  If you want (need?) to compile your
application with MSVC, then you have to build LLVM with MSVC too.
>  
Well then, normalize the crucial interfaces to a extern "C" ABI, or
the reverse, abstract the Windows side API to something well behaved.   Heck,
use COM to glue things together.    Sooner or later Microsoft will come around.

Marcus

"Daniels, Marcus G" <mdaniels at lanl.gov> writes:

[snip]

It is obvious that you don't develop C++ software on Windows for a
living.

Alright, trying to get this conversation back on track...

It seems as though the question to ask is: do the benefits of the C++11
features we want outweigh the cost of alienating users of older compilers?
 For Mac, the question seems almost moot since clang is a fully-supported
compiler.  On Linux, it is most often (always?) possible to bootstrap clang
or a newer GCC, so a baseline like 4.5/4.6 does not seem unreasonable.
 Seems like the same should be true for the BSDs.  It may be a bit of work
to set up, but it should be a one-time deal.  Once a clang 3.1/3.2 binary
is available, all is well.  The problem child, so to speak, is Windows.  I
strongly suggest that support for MSVC *not* be dropped.  There are many
users out there relying on this support.  That said, I think MSVC 2010 is a
reasonable target, at least for 3.3.  And then perhaps move to MSVC 2012
for 3.4.  That should allow for enough time for users to upgrade.

So, can we limit ourselves to MSVC 2010-level support for 3.3?


On Thu, Jan 10, 2013 at 6:45 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> "Daniels, Marcus G" <mdaniels at lanl.gov> writes:
>
> [snip]
>
> It is obvious that you don't develop C++ software on Windows for a
> living.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/6c5f5131/attachment.html>

"Daniels, Marcus G" <mdaniels at lanl.gov> writes:
> Anyway, I thought the question here amounted to how to ensure that
> people can make binaries of LLVM libraries and a working clang
> executable on Windows.
No, it's more than that.  Many (most?) groups integrate clang and/or
llvm libraries into larger projects.

                         -David

On Jan 11, 2013, at 10:02 AM, <dag at cray.com>
 wrote:
> "Daniels, Marcus G" <mdaniels at lanl.gov> writes:
> 
>> Anyway, I thought the question here amounted to how to ensure that
>> people can make binaries of LLVM libraries and a working clang
>> executable on Windows.
> 
> No, it's more than that.  Many (most?) groups integrate clang and/or
> llvm libraries into larger projects.

So it's not a problem that the C++ ABI mapping between clang and MSVC
isn't quite perfect, but it is a problem if the compiled form of the library
isn't embeddable in MSVC projects?   Once you've got the MSVC-built
library, you can't blindly count on using in conjunction with other MSVC
generated things.   I could see there are examples where this wouldn't
matter like OpenCL implementations.   If there is a desire to close the loop (a
Windows hosted clang that is interoperable with MSVC), it is in some sense
useful if Mingw or clang generated object code doesn't quite mimic MSVC. 
That will provide further motive to examine the issues.

Marcus