solvingj
commented
5 years ago This problem is described in a more general way in this issue: https://github.com/conan-io/conan-vs-extension/issues/5
We started from the same initial problem: In the simple naive case, visual studio should specify arch and build_type based on the project configuration. Maybe we can hard code os=windows and compiler=visual studio, and then detect the compiler.version. compiler.runtime looks harder, but should be doable via the plugin.
Unfortunately, very few real-world cases resemble this naive case.
"Configuration" name in visual studio can be any arbitrary string. So, the first thought is to just give users a field to let them override this. Then, we realize that we could give them fields for all the default conan settings... but then what about custom settings in settings.yml? Also, what about Package and dependency options?
Quickly we realize that users actually need to be able to specify any number of arbitrary package and dependency options and settings associated to each visual studio project configuration. This includes specifying one-or-more profiles that would go to the conan command line. Then, we realize users might also want to specify some -e var-vals as well.
Then we should realize from previous experience with Conan that people users will need complete control over the Conan command line which visual studio is going to execute on their behalf. Also, that very often users will want to run multiple Conan commands on the various visual studio events (open solution, switch configuration, clean/rebuild, etc). If we try to provide a GUI configuration facade over Conan Command line, it's going to be too difficult to maintain, and too hard to support what users really need.
This is why we discussed starting by finding the simplest and most supportable way to empower the user to map from visual studio project configurations -> conan command line, and provide string variables representing any information that the plugin can give us about the project, such as ${ARCH}, ${BUILD_TYPE}, etc, and a substitution scheme for crafting a list of conan commands for each event type.
This led to the suggestion of a json schema, very similar to Visual Studio's own CmakeSettings.json... but for Conan. Tomorrow i will try to look into the status of adding these features.
LBHawk
jgsogo
Currently, the extension uses the configuration name as the build_type, and there is no way to override this. This becomes an issue when a project has multiple custom configurations which, from Conan's perspective, all need to map to the same standard "build_type" when installing dependencies.
E.g. an existing project has a "Release" configuration and a "Native_Windows_Release" configuration. It should be possible to specify that the extension should treat "Native_Windows_Release" as just "Release" when installing for the project, as it currently does not work otherwise.