You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 configurations Debug, Release and Retail the ext_prj will often but not always have been set to use RelWithDebInfo in the Retail solution configuration despite the configmap command stating that the project configuration Release should be used in the solution configuration Retail.
What did you expect to happen?
I expect the Release configuration to be the choice for the Retail solution configuration for the external project ext_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:
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: