Incomplete binary distribution windows

If anyone feels this email does not concern them then please ignore it.

Both LLVM-8.0.0-r339039-win64.exe and LLVM-7.0.0-rc1-win64.exe do not create the folder …\LLVM\msbuild-bin and a copy of the main executable renamed to cl.exe in that folder. Mahem ensues.

I’m not writing this for my own purpose, I’ve solved the issue but for those after me.

Have a nice day,

degski

As noted on http://llvm.org/builds/ the installer no longer includes
the Visual Studio integration, instead a new one can be downloaded
from https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain
and that does not rely on having the "fake" cl.exe executable.

Can you share more details on what broke because the installer doesn't
include msbuild-bin/cl.exe? This will also apply to the upcoming llvm
7 release, so it would be good to understand if this causes problems.

Thanks,
Hans

I can theorize that perhaps what breaks is that if you have an old VS integration + LLVM installed, then install a new LLVM, the old VS integration will not be able to find the new clang-cl.exe. I don’t have a good idea on how to address this off the top of my head except perhaps to create the msbuild-bin folder but put a DEPRECATED.TXT file in there so people will find it.

The other problem though is that the new VS integration only works with >= 2017, so if someone can’t upgrade for some reason, this would still be a problem for them. Perhaps we could continue copying the main executable there for backwards compatibility?

I can theorize that perhaps what breaks is that if you have an old VS
integration + LLVM installed, then install a new LLVM, the old VS
integration will not be able to find the new clang-cl.exe.

The old VS integration would also have been uninstalled in that case.

I don't have a
good idea on how to address this off the top of my head except perhaps to
create the msbuild-bin folder but put a DEPRECATED.TXT file in there so
people will find it.

The other problem though is that the new VS integration only works with >=
2017, so if someone can't upgrade for some reason, this would still be a
problem for them. Perhaps we could continue copying the main executable
there for backwards compatibility?

We'd need to keep installing the old integrations also, and I don't
think we want to keep them around. I think the new extension also
supports VS 2015, at least it installs for it but I didn't actually
try the integration there. Supporting 2017 and 2015 is probably
enough.

Let's hear from degski what his reason for needing msbuild-bin/cl.exe was.

Maybe we should just put a bigger note on the download page that the
old integration is gone and people need to get the new one.

Unfortunately the new integration will not work in vs2015. I meant to fix this in the vsix (that was the other change I forgot to push). The reason is that the ability of an extension to properly install itself as a toolchain only became possible in 2017, so there’s no way that I’m aware to even do this in 2015 with a vsix

Yes, I use the old (style), but updated and adapted Clang7/VS2017 integration. If the copy does not exist, the actual compiler being used (even though it doesn’t look like it) is the real cl.exe. So this then chokes on the gcc-style switches/parameters.

degski

Yes, I use the old (style), but updated and adapted Clang7/VS2017 integration. If the copy does not exist, the actual compiler being used (even though it doesn’t look like it) is the real cl.exe. So this then chokes on the gcc-style switches/parameters.

degski

I can theorize that perhaps what breaks is that if you have an old VS integration + LLVM installed, then install a new LLVM, the old VS integration will not be able to find the new clang-cl.exe. I don’t have a good idea on how to address this off the top of my head except perhaps to create the msbuild-bin folder but put a DEPRECATED.TXT file in there so people will find it.

What might happen is that people have VS2015 and VS2017 installed side-by-side, in this case the old integration worked on the VS2015 install and is then thereafter usable from VS2017.

The other problem though is that the new VS integration only works with >= 2017, so if someone can’t upgrade for some reason, this would still be a problem for them. Perhaps we could continue copying the main executable there for backwards compatibility?

It would also require an update to the now excluded props/targets file. The old style integration actually works very well, I’ve added my own switches to it, so that in a project I don’t have any entries in the “other parameters” field. If I then switch compiler clang or cl both work, without touching even the slightest in the rest of the project settings.

degski

There seem to be (not me) an awful lot of people that cannot/don’t want to move from VS15 (or even VS13/12), so the above is unfortunate as we seem to have moved from one extreme to the other. If one assumes a standard installation of VS17, changing the (old) installer batch file to also install for VS17 is not too hard. There is also this utility https://github.com/Microsoft/vswhere, which can help, in case of non-standard installations. I’m not sure whether dealing with those more complex situations is desirable, though. The people with the more complex installations are probably also capable enough to get things working correctly and satisfactory “old school”.

Have a nice day,

degski

Oops. I've updated the manifest, re-published and updated the snapshots.

I meant snapshots *download page*. It previously said 2015 was supported.

I don't think we want to go back to the old integration though, even
if it can be made to work with VS 2017.

It's cool that developers made that work on their own, and unfortunate
that we broke it by not installing a ms-build-bin\cl.exe file. I
suppose we could put that file back, but it also seems like a pretty
narrow use case. Perhaps users who have managed to make the old
extension still work for them could do the copy themselves.

I'm not sure what the best thing to do is here. Shipping the new
integration breaks users who were relying on the old one, but that
also seems inevitable, and maybe worth it for having a new extension
that works well with VS 2017.

- Hans

I don’t think we want to go back to the old integration though, even
if it can be made to work with VS 2017.

No probs.

It’s cool that developers made that work on their own, and unfortunate
that we broke it by not installing a ms-build-bin\cl.exe file. I
suppose we could put that file back, but it also seems like a pretty
narrow use case. Perhaps users who have managed to make the old
extension still work for them could do the copy themselves.

I guess so, I did.

I’m not sure what the best thing to do is here. Shipping the new
integration breaks users who were relying on the old one, but that
also seems inevitable, and maybe worth it for having a new extension
that works well with VS 2017.

I think it’s best to ship the old integration (as it was), that will help quite a lot of peops that cannot/don’t want to move to VS17.

I saw that the plugin will/might support lld in the future, that IS kewl!

Have a nice day,

degski

Agreed, the old way was basically a hack because it was the only way to get it working. But a vsix is the “proper” solution for having an extension. It’s unfortunate that installing a toolchain with a vsix only became possible in 2017, but that’s out of our control.

Shipping the old install batch files as-is but not updated for 2017 I guess is an option

Agreed, the old way was basically a hack because it was the only way to get
it working. But a vsix is the “proper” solution for having an extension.
It’s unfortunate that installing a toolchain with a vsix only became
possible in 2017, but that’s out of our control.

Shipping the old install batch files as-is but not updated for 2017 I guess
is an option

I don't think we should be shipping them since we won't be maintaining them.

The old files are available for anyone to put up on GitHub or
something if they want to maintain them.