search

premake / premake-core

Premake
https://premake.github.io/
BSD 3-Clause "New" or "Revised" License
3.13k stars 611 forks source link

configmap for externalproject does not map correctly #2193

Open jjacobsson opened 3 months ago

jjacobsson commented 3 months ago

premake version: premake5 (Premake Build Script Generator) 5.0.0-beta2 platform: Windows 11 Generating for: vs2022 Lua code that (sometimes) reproduces the problem:

workspace "gen_ext_prj"
    configurations {"Debug", "Release", "RelWithDebInfo", "Profile"}
    project("ext_prj")
        kind "StaticLib"

workspace "configmap_bug"
    configurations {"Debug", "Release", "Retail"}
    externalproject("ext_prj")
        kind "StaticLib"
        configmap { 
            ["Debug"] = {"Debug"},
            ["Release"] = {"RelWithDebInfo"},
            ["Retail"] = {"Release"}
        }

    project("int_prj")
        kind "SharedLib"
        links("ext_prj")
        dependson("ext_prj")

    project("app")
        kind "WindowedApp"
        dependson("int_prj")

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 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.

jjacobsson commented 3 months ago

I tried adding a uuid like this:

externalproject("ext_prj")
    kind "StaticLib"
    uuid "F40FB2C1-4D59-4DB3-81AF-80EC1EE13DA8"
    configmap { 
        ["Debug"] = {"Debug"},
        ["Release"] = {"RelWithDebInfo"},
        ["Retail"] = {"Release"}
    }

It had no effect.

I tried specifying the configurations in the externalproject like this:

externalproject("ext_prj")
    kind "StaticLib"
    configurations {"Debug", "Release", "RelWithDebInfo", "Profile"}
    configmap { 
        ["Debug"] = {"Debug"},
        ["Release"] = {"RelWithDebInfo"},
        ["Retail"] = {"Release"}
    }

This also had no effect.

I tried both at the same time, no effect.