-
-
Notifications
You must be signed in to change notification settings - Fork 617
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
configmap for externalproject does not map correctly #2193
Labels
Comments
I tried adding a
It had no effect. I tried specifying the configurations in the externalproject like this:
This also had no effect. I tried both at the same time, no effect. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
premake version: premake5 (Premake Build Script Generator) 5.0.0-beta2
platform: Windows 11
Generating for: vs2022
Lua code that (sometimes) reproduces the problem:
What seems to be the problem?
After running
premake5.exe vs2022 --file=<the above code in a file>
When opening the generated "configmap_bug.sln" in Visual Studio, opening the Solution Property Pages (right-click solution, select properties) and checking the matrix under "Configuration Properties" for all 3 of the solution configurationsDebug
,Release
andRetail
theext_prj
will often but not always have been set to useRelWithDebInfo
in theRetail
solution configuration despite theconfigmap
command stating that the project configurationRelease
should be used in the solution configurationRetail
.What did you expect to happen?
I expect the
Release
configuration to be the choice for theRetail
solution configuration for the external projectext_prj
always.What have you tried so far?
Re-ordering the entries in the configmap statement. With/without
{}
around the names on the "project" side in the configmap statement.Note:
In the reproducing example I make 2 workspaces, and one of them generates the ext_prj for me with 4 configurations. This block is only there as a replacement for me providing a "proper"
externalproject
solution file in this bug. In our "real" case,ext_prj
is not something premake builds for us, it is provided from a third party. As I bet you can guess it has been generated by cmake based on the names of the configurations. I have not tried messing with the names to see if that does anything.I have also written "sometimes" in a number of places. The thing is, we have nightly build jobs that generate all projects and compiles all the configurations. Some nights they pass. Some nights they fail, because when the incorrect configuration for "ext_prj" is chosen in the "Retail" solution configuration our code no longer links. The not linking part is expected of course, that is just how we noticed this problem happening. I have run the example I have pasted above a number of times and the problem appears about 4 out of 10 runs. I clean out the generated .vcxproj, .sln, any .user and the .vs folder files completely between each run.
And as always: fully expecting this problem to reside somewhere between the keyboard and the back of the office chair and not the software.
The text was updated successfully, but these errors were encountered: