Native platform and namestyle

[KageKirin]

Hi there,

I'm having a few issues with building generated projects on Windows, using Ninja (and clang), and as far as I have researched, it's linked to platform "native".

• solution configuration: my solution configuration is pretty straightforward. In fact, it's based on GENie's configuration, without many additions. I'm not using toolchain.lua from BX (yet).

• projgen: this one as well is basically projgen-windows from GENie's makefile:

  projgen-windows:
    $(SILENT) $(GENIE) --to=../build/$(PROJECT_TYPE).windows --os=windows $(GENIE_OPTIONS) $(PROJECT_TYPE)
  

• the issue: the generated ninjafiles have .a as target extension for static libs, which should be .lib on Windows, even when compiling with GCC or Clang.

• (what I found as) the cause:

  • in project.lua: premake.getnamestyle() searches for an existing value in premake.platforms["Native"] or premake.gettool() or returns posix.
  • premake.platforms["Native"] has no field for namestyle hence getnamestyle() returning posix.
  • posix in turn is then correctly used to retrieve the extensions for static libs

So far, I found an "easy" fix, namely to simply set namestyle.

		Native =
		{
			cfgsuffix       = "",
			namestyle       = os.is("windows") and "windows" or nil,
		},

This solves the issue at hand, but I think we could have a more flexible solution by exposing namestyle as API field. This way, it would be simple to set

configuration {"windows"}
namestyle "windows"
configuration {}

in the solution.

What do you think? I can submit a PR of either my current solution or of the flexible solution.

Cheers.

[bkaradzic]

You can't decide about namestyle based on OS. For example generating project files on Windows OS for Linux. Or generating project files on Linux OS for MSVC Windows (.lib) vs. MinGW Windows (.a).

[bkaradzic]

Also whole OS is really deceptive because it's about where things are generated, not exactly for which platform which causes confusion all the time.

[KageKirin]

Interestingly, os.get() / os.is() depend on the --os option if provided.

	function os.get()
		return _OPTIONS.os or _OS
	end

	function os.is(id)
		return (os.get():lower() == id:lower())
	end

IMHO, it's safe to assume that if you target Windows as OS by providing --os=windows you want Windows-style libs (.lib).

[KageKirin]

Also, if we do it with an API field

configuration {"windows"}
namestyle "windows"
configuration {}

we can leave the configuration and its assumptions to the user.

[bkaradzic]

IMHO, it's safe to assume that if you target Windows as OS by providing --os=windows you want Windows-style libs (.lib).

This assumption is not true if you're building with MinGW on Windows. It's really toolchain specific.

[KageKirin]

I see. It's my first time using a different toolchain than MSVC on Windows (namely clang + ninja), and obviously I'm running into all those small issues.

[bkaradzic]

For clang on Windows (unless one from MSVC, not sure if that's still supported) you should use .a for libraries, because the rest of toolchain expect that.