-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native platform and namestyle #502
Comments
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). |
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. |
Interestingly,
IMHO, it's safe to assume that if you target Windows as OS by providing |
Also, if we do it with an API field
we can leave the configuration and its assumptions to the user. |
This assumption is not true if you're building with MinGW on Windows. It's really toolchain specific. |
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. |
For clang on Windows (unless one from MSVC, not sure if that's still supported) you should use |
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:
project.lua
:premake.getnamestyle()
searches for an existing value inpremake.platforms["Native"]
orpremake.gettool()
or returnsposix
.premake.platforms["Native"]
has no field fornamestyle
hencegetnamestyle()
returningposix
.posix
in turn is then correctly used to retrieve the extensions for static libsSo far, I found an "easy" fix, namely to simply set
namestyle
.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 setin the solution.
What do you think?
I can submit a PR of either my current solution or of the flexible solution.
Cheers.
The text was updated successfully, but these errors were encountered: