Clang support

[Maxim Vafin]

On Windows:

When I try to build using Clang by specifing --tc=clang I get

scons: *** No version of CLANG was found on the system for target win32-x86_64

When I looking in the Parts sources for how it finds Clang I can only find Linux paths not Windows. It seems to me that Clang for Windows is not supported by Parts. Am I right or doing something wrong?

On Linux:

When building using Clang with target equal to host, e.g x86_64 target on x86_64 host machine I can just specify --tc=clang cmdline argument and build works as expected. But when trying to do the same for building when host is not equal to target, e.g x86 target on x86_64 host machine parts complain on no GCC_VERSION in env while resolving gas tool. To solve that I use --tc=clang,gnutools, but it seems explicit to me. Is it expected behavior or bug?

[Jason Kenny]

Hi,

So I only have clang on mac and Linux and android NDK ( I am sure I need to update the NDK code to support new versions) at the moment. I have not had time to add it for windows ( plan to... but i plan a lot of things I yet to do :-) ). There nothing preventing the addition of clang for windows.. just a some toolinfo about where to find it for that combination and a tweak on the tool file itself as windows does not have a "gnu" like layout.

As far as the issue on Linux. there is probably a bug in the toolchain logic. I honestly only added it, only had limited use of it when I was Intel before I told we all had moved to a new company. I have not gotten back to cleaning up clang yet. You might want to provide you own clang toolchain, or you can tweak the existing one in parts/toolchain/clang.py . You can add you own in parts-site/toolchain/clang.py to override this. I agree that clang should not need gnutools defined. mstools and gnutools are defined to control "leach" like compilers like the Intel compiler that use an installed version of the compiler to ensure compatibility and to do the linking. It is used to control which version that compiler toolchain to use.

If you get a fix, feel free to submit a pull request. Otherwise you can wait till I get around to fixing this. Feel free to ask me any questions if you plan to fix this yourself. I will be happy to help explain anything going on in Parts

[Maxim Vafin]

Thanks to your suggestion, I fixed the Linux issue by adding gas.py to parts-site/toolchain/ folder in my repo with the following code:

def gas_setup(env,ver):
    if env.get('GCC_VERSION') is None:
        env['GCC_VERSION']=ver


def resolve(env,version):
    del env
    func=lambda x : gas_setup(x,version)
    return [('gas',func)]

I also added configurations clang_any-x86_64_any-x86.py and clang_any-x86_any-x86_64.py to default config. It worked for me, I can make a pull request with this changes if you want. I also think that maybe it makes sense to create GAS_VERSION variable in env for gas tool.

[Jason Kenny]

Please add a pull request!

If anything one might argue that the gas tool is not needed as this tool is a gnu Assembler. I am not sure if this make sense in a Clang setup I think it should be more of a llvm-as tools or something. Technically gas should be part of the bintools logic more than Gcc I believe, as it comes with bin tools. Anyways this is why I never thought the clang was done 100% right as it was sort of copy the gcc logic and replace it gcc with clang, which is technically not the "correct" thing to do but it works. Don't worry about making it perfect.. I will be happy to take in any improvement. I recall I had a config i had tested with clang which added back in the color when it ran in Parts. I forget the option but it forced color on. You might want to add that in your default config as the color error messages are nice to see when fixing up compiler errors with clang.

[Eugene Leskinen]

Yes. Gas is part of GNU Binutils and we have parts/toolchain/binutils.py for it. It is strange to me that it requires GCC_VERSION instead of BINUTILS_VERSION

[Jason Kenny]

As I recall we had added in binutils as a separate thing because of build cases in which the "system" binutils had a bug in it and the fix/hack was to use a newer custom version google had made. Ideally gcc when it is built is bound to a version binutils, so normally one does not select different version of binutils. I would expect this was more of getting it working, vs getting it right at the time, and then after that it sort of feel in the cracks.

Given this issue is about getting Maxim moving and hopefully getting a fix we can share for everyone else. I think the best quick fix is to remove gas tool from clang. (still adding the gas toolchain would be a useful addition to avoid issues)

More long term is to look at if the at gnulink tools are correct for use with clang.