Closed jgsogo closed 5 years ago
Indeed, if the functionality is provided by the extension already, it seems _multi
is not really necessary.
A different topic would be if this idea could be generalized and implemented in the multi generator, to solve the issues pointed by @SSE4, but I guess the idea is that using the extension, the internal mechanism can be transparent, so go ahead.
ping @solvingj in case he can think of some other case that would make sense
some history:
https://github.com/conan-io/conan-vs-extension/issues/7
https://github.com/conan-io/conan-vs-extension/issues/8
let's make visual_studio
the default one, and eventually we may even remove visual_studio_multi
, if it's not used/needed
A new project in Visual Studio uses two default configurations:
Release
andDebug
and the platformsx64
andx86
(taken from Visual Studio 2019). The user is free to introduce new configurations with custom names, the settings corresponding to those configurations are stored in the properties of the project.When this extension uses the
visual_studio_multi
generator with it creates just a single.conan/conanbuilldinfo_multi.props
file with severalif
clauses to include the matching property file with the corresponding 3rd party information.Let's have a look at those files for a project with
Debug
andCustomDebug
configurations:.props
file.props
file? There are several conditions and depending on the value of those variables different.props
file is included.This works with the default configurations,
Debug
andRelease
, but it is a problem when the configuration has a custom name likeConfigDebug
because it is not going to match any of those conditions and no property file is going to be included. The workaround for this is to add that custombuild_tuype
to the Conan settings, provide the flags to the libraries in the environment variables, modify recipes that are using the regularbuild_type
values to do some checks,... IMO it is too much to document and too much work from the user perspective.I see no easy solution for that problem right now.
I suggest to deprecate the
visual_studio_multi
generator for this extension (at least until we find a proper solution). The functionality is perfectly covered by thevisual_studio
generator because, although all the property files generated by it have the same name, they are generated in different folders and the conditions to choose which one to include are handled by Visual Studio itself. This is an example of the project file when using thevisual_studio
generator:And this works like a charm, Visual Studio evaluates the right condition and includes the file with the information about the dependencies.
ping @lasote, this is relevant, I don't know if there is something we can do related to the
visual_studio_multi
to handle these custom configuration names. ping @memsharded, wdyt? do we needvisual_studio_multi
generator for this extension?Thanks