Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

visual_studio generator variables #1430

Merged
merged 3 commits into from Oct 3, 2019

Conversation

memsharded
Copy link
Member

No description provided.

@@ -24,30 +24,45 @@ Generated xml structure:
<Conan-Lib2-Root>{PACKAGE LIB2 FOLDER}</Conan-Poco-Root>
...
</PropertyGroup>
<PropertyGroup Label="ConanVariables">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/home/travis/build/conan-io/docs/reference/generators/visualstudio.rst:16:Could not lex literal_block as "xml". Highlighting skipped.

@lasote lasote merged commit 2913dbf into conan-io:master Oct 3, 2019
@memsharded memsharded deleted the feature/vs_generator_variables branch October 3, 2019 15:19
@adaviding
Copy link

adaviding commented Mar 16, 2020

The usage of ConanVariables is a fine idea, but it threw me for a curveball. I was thinking about asking you to update your documentation, but I'm not sure if there is an easy way to describe the curveball I received. I will describe it here and maybe you will find an easy way to describe it (if possible).

I have one VisualStudio project that imports a conanbuildinfo.props. Then on the same project, I have an export.props file which looks kind of like this (notice how it includes the conanbuildinfo.props):

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ImportGroup Label="PropertySheets">
    <Import Project="conanbuildinfo.props" />
  </ImportGroup>

  <!-- some other stuff -->

</Project>

Then I have a second Visual Studio project (a GTest project) which consumes the first project via its export.props. The second project pulls in its own conanbuildinfo.props (which adds a conan package for GTest).

Now in the *.vcxproj file for the second project, I was pulling in the conanbuildinfo.props before the export.props like this, and I had a build error was that gtest/gtest.h could not be found.

  <ImportGroup Label="PropertySheets">
    <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
    <Import Project="conanbuildinfo.props" />
    <Import Project="..\..\Panopto.Native.Media.Lib\export.props" />    
  </ImportGroup>

I eventually fixed the build error by switching the order of the XML fields so that export.props came before conanbuildinfo.props:

  <ImportGroup Label="PropertySheets">
    <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
    <Import Project="..\..\Panopto.Native.Media.Lib\export.props" />
    <!--This needs to come after all of the `export.props` imports because of something odd about how intermediate variables are defined and then can be redefined before they are evaluated.-->
    <Import Project="conanbuildinfo.props" />
  </ImportGroup>

Apparently, the intermediate ConanVariables were being redefined in the export.props prior to being evaluated in the conanbuildinfo.props file. It took me a day to solve this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants