conan-io / conan-vs-extension

Conan Extension for Visual Studio
https://marketplace.visualstudio.com/items?itemName=conan-io.conan-vs-extension
MIT License
59 stars 34 forks source link

'visual_studio_multi' generator doesn't work without custom configurations #108

Closed jgsogo closed 5 years ago

jgsogo commented 5 years ago

A new project in Visual Studio uses two default configurations: Release and Debug and the platforms x64 and x86 (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 several if 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 and CustomDebug configurations:

  <ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='CustomDebug|x64'">
    <Import Project=".conan\conanbuildinfo_multi.props" />
  </ImportGroup>
  <ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    <Import Project=".conan\conanbuildinfo_multi.props" />
  </ImportGroup>
<?xml version="1.0" ?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <ImportGroup Label="PropertySheets">
        <Import Condition="'$(Configuration)' == 'Debug' And '$(Platform)' == 'Win32' And '$(PlatformToolset)' == 'v142'" Project="conanbuildinfo_debug_win32_v142.props"/>
        <Import Condition="'$(Configuration)' == 'Release' And '$(Platform)' == 'Win32' And '$(PlatformToolset)' == 'v142'" Project="conanbuildinfo_release_win32_v142.props"/>
        <Import Condition="'$(Configuration)' == 'Debug' And '$(Platform)' == 'x64' And '$(PlatformToolset)' == 'v142'" Project="conanbuildinfo_debug_x64_v142.props"/>
        <Import Condition="'$(Configuration)' == 'Release' And '$(Platform)' == 'x64' And '$(PlatformToolset)' == 'v142'" Project="conanbuildinfo_release_x64_v142.props"/>
    </ImportGroup>
    <PropertyGroup Label="UserMacros"/>
    <PropertyGroup/>
    <ItemDefinitionGroup/>
    <ItemGroup/>
</Project>

This works with the default configurations, Debug and Release, but it is a problem when the configuration has a custom name like ConfigDebug 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 custom build_tuype to the Conan settings, provide the flags to the libraries in the environment variables, modify recipes that are using the regular build_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 the visual_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 the visual_studio generator:

  <ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='CustomDebug|x64'">
    <Import Project="..\x64\CustomDebug\.conan\conanbuildinfo.props" />
  </ImportGroup>
  <ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    <Import Project="..\x64\Debug\.conan\conanbuildinfo.props" />
  </ImportGroup>

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 need visual_studio_multi generator for this extension?

Thanks

SSE4 commented 5 years ago

seems to be related: https://github.com/conan-io/conan/issues/2857 https://github.com/conan-io/conan/issues/2759

memsharded commented 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

SSE4 commented 5 years ago

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