Windows interface for clang

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Windows interface for clang

Russell Wallace
I've finally developed what I think is a general solution to the problem of building existing Windows programs with clang:


Using this, I've managed to run attempted builds of Python, Ruby and Perl.

Python 2.7 works - it generates a python.exe that at least passes a preliminary smoke test.

Perl generates an executable that crashes partway through the build. I'll try to narrow it down further.

Ruby fails with an error message at the configuration step. I'm trying to find out why; it might be something easily fixable.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Windows interface for clang

Chandler Carruth-2
This seems more relevant to cfe-dev.

On Thu, Jul 9, 2015 at 5:54 PM Russell Wallace <[hidden email]> wrote:
I've finally developed what I think is a general solution to the problem of building existing Windows programs with clang:


You seem to be struggling with the need to name the binary 'cl.exe'. Last time I checked, we installed clang-cl.exe under that name in a specialized director specifically so you can use build systems relying on that name.

-Chandler
 


Using this, I've managed to run attempted builds of Python, Ruby and Perl.

Python 2.7 works - it generates a python.exe that at least passes a preliminary smoke test.

Perl generates an executable that crashes partway through the build. I'll try to narrow it down further.

Ruby fails with an error message at the configuration step. I'm trying to find out why; it might be something easily fixable.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Windows interface for clang

Russell Wallace
On Fri, Jul 10, 2015 at 2:00 AM, Chandler Carruth <[hidden email]> wrote:
This seems more relevant to cfe-dev.

Okay. 

You seem to be struggling with the need to name the binary 'cl.exe'. Last time I checked, we installed clang-cl.exe under that name in a specialized director specifically so you can use build systems relying on that name.

Right, but:

1. The existence of a binary named cl.exe isn't enough; depending on the circumstances, the build system may look specifically in the visual studio directory. Of course, you could do the rename/copy by hand, but it's better to have it automated, particularly since in practice there is a need to switch back and forth.

2. Python at least needs to have it switchable specifically for 32-bit or 64-bit builds.

3. wic also supplies the option -Wno-invalid-token-paste which is necessary for compatibility with the Microsoft preprocessor. I intend adding other options as needed.

4. Hopefully can also substitute calls to the llvm linke when that's ready for prime time.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Windows interface for clang

Reid Kleckner-2
On Thu, Jul 9, 2015 at 6:18 PM, Russell Wallace <[hidden email]> wrote:
On Fri, Jul 10, 2015 at 2:00 AM, Chandler Carruth <[hidden email]> wrote:
This seems more relevant to cfe-dev.

Okay. 

You seem to be struggling with the need to name the binary 'cl.exe'. Last time I checked, we installed clang-cl.exe under that name in a specialized director specifically so you can use build systems relying on that name.

Right, but:

1. The existence of a binary named cl.exe isn't enough; depending on the circumstances, the build system may look specifically in the visual studio directory. Of course, you could do the rename/copy by hand, but it's better to have it automated, particularly since in practice there is a need to switch back and forth.

For MSBuild, you can pass along /p:PlatformToolset=LLVM-vs2013 (or edit the project file for the same effect) to bypass this. I know Python's build is based on VS projects, so I would've expected this to work there. I wouldn't know about Ruby or other builds, and I imagine swapping the binary is useful for particularly inflexible systems.

2. Python at least needs to have it switchable specifically for 32-bit or 64-bit builds.

3. wic also supplies the option -Wno-invalid-token-paste which is necessary for compatibility with the Microsoft preprocessor. I intend adding other options as needed.

Was the issue here in user code or a system header? If the invalid token paste came from a system header, we shouldn't have errored. If it's in user code, it's up to them to decide if they want to suppress the issue by adding the flag themselves or fix it for conformance.

Different users have different needs, so it's not clear where the default level of conformance diagnostics vs. compatibility should be. I guess we should probably downgrade this to a -Wmicrosoft warning or something when MS compatibility is on.
 
4. Hopefully can also substitute calls to the llvm linke when that's ready for prime time.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Windows interface for clang

Russell Wallace
On Wed, Jul 15, 2015 at 5:11 PM, Reid Kleckner <[hidden email]> wrote:
> For MSBuild, you can pass along /p:PlatformToolset=LLVM-vs2013 (or edit the project file for the same effect) to bypass this. I know Python's build is based on VS projects, so I would've expected this to work there. I wouldn't know about Ruby or other builds, and I imagine swapping the binary is useful for particularly inflexible systems.

Right, as you say, msbuild is relatively flexible and Python uses it, so you would expect such techniques to work there, but unfortunately they don't - I didn't use that particular flag, but I used similar ones that allow pointing msbuild at a different compiler and it failed because regardless of whether you select a 32 or 64 bit build, Python for some reason requires some object file to be compiled 32-bit and some other one to be compiled 64-bit.


Was the issue here in user code or a system header? If the invalid token paste came from a system header, we shouldn't have errored. If it's in user code, it's up to them to decide if they want to suppress the issue by adding the flag themselves or fix it for conformance.

User code, Python again. Mind you, I'm not disagreeing with you about the scenario where one is writing new code with a view to making sure it works with clang from the start. It's just that I'm dealing with the trickier scenario where one is trying to compile a large quantity of code that has already been written by other people without regard to clang. 

Different users have different needs, so it's not clear where the default level of conformance diagnostics vs. compatibility should be. I guess we should probably downgrade this to a -Wmicrosoft warning or something when MS compatibility is on.

I think so, yes. Greenfield projects can easily add flags for tighter conformance checking if so desired.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev