Improve how the conanfile is searched

[jgsogo]

Currently, the code is iterating from the path where the project is to the root folder looking for a conanfile.py or conanfile.txt file, and it will run Conan using that file.

IMO, the plugin should use only a conanfile if it has already been included in a project (like any other cpp file or resource file). This way, the user will have a visual hint and will know which file is being used in which project and also it will be easier to find for the extension itself.

wdyt @SSE4?

PS.- If there are several suitable files in the same project, the plugin should raise an error. PS2.- It will also make the Conan install at solution level useless (right now I'm not sure what is the intention of it), or at least it will have a meaning: just run Conan for all the projects.

[SSE4]

yes, totally agree, in my opinion, we have to use the following algorithm:

1. scan project items for conanfile.[txt|py]
2. scan solution items for conanfile.[txt|py]
3. scan directories, like it's currently done, but looking into subdirectories as well, in this case the following layout should work:

\build
  project.vcxproj
\src
  conanfile.txt

PS1. - not sure. solution may use top-level conanfile for the entire build, but specific one for tests (e.g. adding gtest library) PS2. - it's not useless, the intention is to install into every project which have conanfile, or in every project if we have a conanfile on the solution level

[jgsogo]

I think that in Visual Studio there is not such thing as solution items, you cannot add a file to a solution, you need to add it always to a project (that's also my motivation for the PS2).

And about (3) I think that the natural visual studio philosophy is to use only the files that are added to the project, and I think that making it that way will simplify a lot the algorithm to look for the conanfile: if there is one, use it; if there are more than one, error; if there isn't any, nothing happens.

[jgsogo]

🤦‍♂ Solution items:

[SSE4]

@solvingj we need your input on this one :) what's your workflow regarding conanfile location? do you have it added to the project items or solution items? do you use it in the root project folder, or in build sub-folder near to the projects, or outside of the project folder?

[jgsogo]

It has bitten me again! I've opened a VS solution, there was a conanfile.txt in some directory and the plugin has started to build and include props file, and this project was already handling the Conan dependencies because it was generated from a CMake solution.

[solvingj]

We have not added conanfile to our solutions, although I think I could get that approved here. On the other hand, I know I could not have gotten that approved 6 months ago.

We have an _automation subdirectory which we keep conanfile.py in. As I've stated many times, I'd want the plugin to look for a standard .json config file that lets me specify the path to conanfile.py and other options about conan behavior. If this file doesnt exist (and until the feature is added), I really only like the default search behavior of looking in solutionDir and then each projectDir.

In any case, a global option in the plugin that says "automatically do this when I open solution/project" makes sense for users who want to disable all or some startup behavior. Ideally, if you could reliably detect the scenario @jgsogo reached, and avoid the undesired behavior, that would be desirable also.

Also, RE: the point about the "philosophy of only process what is in solution". I like it, but it doesn't apply to us, and I would have been frustrated if the only way to make the Conan plugin do it's work was to add the conanfile.py to my project. So, again, I would suggest a project-level option and global-level option here: skip conanfiles not added to visual studio project or something.

With the Visual studio cmake support having been around for years, it seems strange to me that people still use CMake to generate a visual studio projects, and then manually open them in visual studio project (although I know people do that ). I would not try to support that case. I would support the two cases:

1. User opens visual studio solution/project (immediate goal)
2. User opens cmake project with OpenFolder/OpenCmake: (future goal)

[jgsogo]

Yes, I think that the approach could be:

1. If there is a conanfile.py or conanfile.txt added to the project or to the solution items, use it (higher priority for the project specific one).
2. look for the file in the project folder
3. look in the solution dir (it what MSFT does for .vsconfig file)

[solvingj]

Follow existing logic seems good. Is it same process for CMakeSettings.json?

[jgsogo]

According to this: "The new CMakeSettings.json file is placed alongside the project’s root CMakeLists.txt." and having a look at the screenshots it is always added to the solution.

[talyz]

For my use case, it would be important that this not only acts as a blacklist / whitelist, but also makes it possible to include a conanfile.txt not residing in a parent or descendant of the project folder. Our structure is essentially this:

• /source/winproj/ is the Windows project folder
• /build/conan/ is where our conanfile.txt and other conan-related files are