Generate MSVS-version-independent project files and multiple version-specific solutions?

[vadz]

Hello,

I'd like to be able to use premake to generate version-independent project files for MSVS, i.e. instead of running premake5 vs2017 and premake5 vs2019 and premake5 vs2022 I'd like to have a generator that I could use with premake5 msvs which would create a single set of .vcxproj files that could be used with any of these versions and one or more solution files, which would use these project files.

IME this works much better than having multiple version-specific projects that mostly are exactly identical and I've been using this (with other project-generating tools) for many years, but I don't think it's currently possible to do this with premake, is it? If yes, I'd be glad to hear about it, but if no, I'd like to ask whether anybody can give me any hints about how could this be implemented and, also, whether contributing such msvs action back to premake itself would be welcome?

Thanks in advance for your thoughts!
VZ

[nickclark2016]

So currently, I don't believe this is supported in Premake. There is currently logic depending on the version of Visual Studio requested in the project files. We also provide a version number for the solution format version in the solution file, which corresponds to the version of the solution. When you have a version agnostic project, how is the format version handled in the solution? Also, how are fields in new versions of VS handled by old versions?

We're definitely open to having a PR for a "vs" action, but there are definitely questions that would need to be answered.

[vadz]

Thanks for your answer, Nick!

When you have a version agnostic project, how is the format version handled in the solution?

We could still have different solutions for the different MSVS versions, this is what we do with the different wx_vcNN.sln files in this directory, for example, where you can see 7 of them for MSVS 2010, 2011, ..., 2022. But the gain from not having 7 versions of each and every .vcxproj file is still very appreciable.

Also, how are fields in new versions of VS handled by old versions?

I'm pretty sure this could be done using Condition="'$(VisualStudioVersion)' == 'NN'" in the projects (possibly indirectly, via an included .props file), but we haven't had any need to do this. If you need some option only supported by a compiler version greater than some N (e.g. /std:c++17), then you probably can't support any versions before N anyhow, so you could just use it directly. I expect very few people to want to support anything like MSVS 2010, but it seems reasonable to support MSVS 2017, 2019 and 2022 right now, and it's still much nicer to not have 3 sets of projects.

We're definitely open to having a PR for a "vs" action, but there are definitely questions that would need to be answered.

Would it be better to answer these questions before working on this PR or should I try to come up with something and then submit it for the discussion?

Thanks again!

[nickclark2016]

I think a good first step would be to develop a plugin where we can see this in action as a MVP. I definitely believe that this could be beneficial and could replace the current vstudio plugin in the long term. From a design standpoint, I'd want to know things like:

• How does the user interact with setting the version of VS that you want to generate for? What happens when no version is provided (do we assume 2010, latest in Premake, or try to search the system for the latest version installed)
• How can we define which flags (and values associated with those flags) are supported for each version of Visual Studio, as well as for each architecture and toolset?

In an MVP, I'd expect to see these types of questions addressed, as well as thorough testing for the provided functionality.

Now, my next concern is if this is something that would ship with a 5.x version versus integration with 6.x as the default. That's where I'd like to rope in @starkos for his thoughts. My thoughts are that this would be easier to do in 6.x, as there is less technical debt to work around.

We can definitely keep this discussion open for chatting about various questions and thoughts as you're developing (if you're volunteering to tackle this).

[vadz]

I think a good first step would be to develop a plugin where we can see this in action as a MVP.

OK, I'll try to do it. It might take me some time though as I'm completely new to Premake (and not very comfortable with Lua, even though I used it in the past).

* How does the user interact with setting the version of VS that you want to generate for?

In the currently used tool we require specifying the names for all the solution files to produce explicitly. I don't know if we could (probably?) or should (really no idea) do it like this with Premake, but this seems to work reasonably well, e.g. in practice you'd typically add a few options specifying the solution file names for the versions you support once and then update them when adding support for the new version of MSVS or dropping support for an old one.

* How can we define which flags (and values associated with those flags) are supported for each version of Visual Studio, as well as for each architecture and toolset?

From what (little) I know about Premake syntax, it could make sense to use filter for this, perhaps?

Now, my next concern is if this is something that would ship with a 5.x version versus integration with 6.x as the default. That's where I'd like to rope in @starkos for his thoughts. My thoughts are that this would be easier to do in 6.x, as there is less technical debt to work around.

OK, thanks, this is important, as I'd need to look at 6.x then -- so far I've only looked at 5, as I thought it was the latest version (and it's not even yet available in even the latest Debian, for example, where only premake4 package exists).

We can definitely keep this discussion open for chatting about various questions and thoughts as you're developing (if you're volunteering to tackle this).

I'd like to try because we really need some solution for MSVS projects generation not relying on obsolete Python 2 (used by our current tool), but I don't promise anything yet, let's see how it goes first...

Thanks again for your help!

[nickclark2016]

* How can we define which flags (and values associated with those flags) are supported for each version of Visual Studio, as well as for each architecture and toolset?

From what (little) I know about Premake syntax, it could make sense to use filter for this, perhaps?

This is more a question from the perspective of Premake code, not user code. We currently have different files that represent various VS versions. For your approach, we'd need a mechanism for the generator to query what flags each version of VS supports and which values of those flags are supported by each version. I'd expect something like:

local flag_19 = vs2019.fetch_value(my_flag, api_value)
if flag_19 ~= nil then
  // add it here
end

Or more generically, I'd expect to do something like this:

local flags = vstudio.fetch_value(my_flag, api_value)
-- flags is a table of versions and the values to emit

[vadz]

Looking at modules/exporters/vstudio/vstudio.lua in 6.x branch I don't see any existing tests like this. In master things are less clear (to me, at least) but I can't find any version-dependent flags like this, so are we even sure we need them at all?

[nickclark2016]

In 6.x, it's still an MVP, so we don't have anything beyond bootstrapping for VS in 6.x. In master, you'd need to look at the vcxproj generator and look for where we compare _ACTION against things like "vs2022", "vs2017", etc.