5.0.0-beta3 defaults to gcc on BSD

[seragh]

What seems to be the problem?
Without --cc=clang premake generates makefiles using gcc on FreeBSD (gmake2 action)

What did you expect to happen?
Clang is used instead.

What have you tried so far?

How can we reproduce this?
bootstrap premake

What version of Premake are you using?
5.0.0-beta3

Anything else we should know?
Regression wrt 5.0.0-beta2

[tritao]

https://github.com/premake/premake-core/blob/master/src/_premake_init.lua#L1358

I think we need to update this to:

	filter { "system:darwin or bsd" }
		toolset "clang" 

My only concern here is Premake only has a generic bsd system, and probably not all should default to clang.
So we probably need to extend system with a new freebsd entry, and maybe just use the os.systemTags functionality for generic BSD checking.

@nickclark2016 @samsinsane any thoughts?

[seragh]

Should be a check if clang is available then use clang, then check for gcc and lastly simply cc/c++?

[tritao]

Should be a check if clang is available then use clang, then check for gcc and lastly simply cc/c++?

That works, but that's not really how Premake is currently designed. AFAIK it does not do any automatic checking of toolsets at generation time.

Another possibility which was suggested in #2207, it to have a system toolset, quotiong:

For the system compiler, a new toolset "system", can be added, default to C = cc and CXX = c++`.

[seragh]

The linked issue mentions the use case of pre-configuring a project and shipping the generated build files. This is a valid scenario and should remain supported, I think this is covered by explicitly specifying toolchain and action.

The primary role I see for premake is for it to be used similar to gnu ./configure and cmake, ie as a means to configure things like install prefix or which features to enable, then hand it of to make, nija, visual studio or whatever. In that capacity it make sense to have some level of detect system toolchain and use it if not specified otherwise.

I guess I could add this select a usable toolchain logic to my premake5.lua but feel this should be handled out of the box.

[nickclark2016]

https://github.com/premake/premake-core/blob/master/src/_premake_init.lua#L1358

I think we need to update this to:

	filter { "system:darwin or bsd" }
		toolset "clang" 

My only concern here is Premake only has a generic bsd system, and probably not all should default to clang. So we probably need to extend system with a new freebsd entry, and maybe just use the os.systemTags functionality for generic BSD checking.

@nickclark2016 @samsinsane any thoughts?

Seems reasonable. Given it sounds like Clang is the default on BSD (I really do not interact with that OS ecosystem at all, so someone feel free to correct me), we should at least default ourselves to Clang there.

[seragh]

Seems reasonable. Given it sounds like Clang is the default on BSD (I really do not interact with that OS ecosystem at all, so someone feel free to correct me), we should at least default ourselves to Clang there.

All recent BSD images I used came with clang (not sure how representative that is, but my feeling is vast majority), so my pick for sensible default if there is no checking would indeed be clang for BSD. On the other hand there are Linux distros using clang instead (haven't used any so far myself), still gcc should clearly be a more reasonable first pick for Linux.

The proposed change I see sufficient to address this report, still the idea of checking if it is usable and falling back to the next choice in line sound desirable.

[nickclark2016]

Yeah, this is a bit tricky. I think the stop gap is to change it to use clang by default, but there will probably need to be a larger effort to determine the appropriate default toolset dynamically, if we decide to go down that route.

[samsinsane]

I think expanding the existing functionality to detect the toolset would make more sense than just continuing with the sweeping generalisations. When the host and target OS are the same, we have the ability (on systems that support it) to query cc --version and c++ --version, if either output contains clang or Clang then we default to Clang otherwise GCC. When the host and target OS aren't the same, then we fall back to the sweeping generalisations since it's the best we can do.

Regarding the generated file portability, the main issue is being unable to change what is being generated. We can already change the toolset, so there's no real issue with auto-detecting the system toolset when possible. Additionally, I would imagine users on a Clang-based system that share generated files would already be handling the toolset explicitly which diminishes the impact further.