Working directories differ under various CLI commands

I haven’t fully explored all scenarios, but in experimenting with various Conan commands I have a concern that many recipes have been written in such a way that they will be incompatible with many current and future commands. Many packagers have not explored a majority of the packaging commands outside of conan create ... and so they have not discovered this yet, but as I have explored the new commands I found a few things. Here is one example, i will come back and add others as i stumble across them.

In summary, the problem is that many recipes are written leveraging the relative path which depends on a combination of the the conanfile.py method and the conan command used to invoke Conan. I think Conan needs to enforce “working directory” consistency across all commands. The only alternatives are to leave it as is, or “tell everybody about it and recommend absolute paths via documentation” which is problematic.

Here is the recipe used in the example below: https://github.com/bincrafters/conan-libhandler

Example Synopsis

On recipe libhandler, package is created successfully:

conan create bincrafters/stable

Immediately after, the recipe is re-tested, and the test fails on the build step:

conan test . libhandler/0.5@bincrafters/stable

The error states that the .sln file cannot be found. Here is the path definition, which is relative to the build directory. We know this path is correct because the conan create command worked.

    def build_vs(self):
        sln_path = os.path.join("sources", "ide","msvc","libhandler.sln")

However, the error in the log below shows that under the conan test command, some other working directory is in effect. Most likely, the working directory is the test_package directory.

libuv/1.15.0@bincrafters/stable: Already installed!
libhandler/0.5@bincrafters/stable: Already installed!
libhandler/0.5@bincrafters/stable test package: Generator txt created conanbuildinfo.txt
libhandler/0.5@bincrafters/stable test package: Generated conaninfo.txt
libhandler/0.5@bincrafters/stable test package: Running build()
vswhere detected VS 15 in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community
libhandler/0.5@bincrafters/stable test package: Running command: set "VSCMD_START_DIR=%CD%" && call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\../../VC/Auxiliary/Build/vcvarsall.bat" amd64 && devenv sources\ide\msvc\libhandler.sln /upgrade && msbuild sources\ide\msvc\libhandler.sln /p:Configuration=Release /p:Platform="x64" /m:8 /target:libhandler
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.4.4
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

Microsoft Visual Studio 2017 Version 15.0.27004.2009.
Copyright (C) Microsoft Corp. All rights reserved.

The following files were specified on the command line:

        sources\ide\msvc\libhandler.sln

Note

There are actually two issues here. The one I explained above. The second is that I don’t believe the build() method should even have been executed in the above example of conan test command. If someone can easily explain this second mystery away, great. Otherwise, please focus on the first and primary issue.

[giraldeau]

I had the same issue with trying to run only the package command. The build is very long to execute, to save time I wanted to run only the package step to iterate quickly and fix the packaged files. However, the files are not copied when running only the package step, but are found when doing a full create. When package() is called by the create command, the working directory is the build directory, and when executing the package command, the current directory is the directory at the moment the command runs. I don’t understand what is the purpose of specifying --build-folder to the package command if it is not used to copy files. Executing the create or package commands should work basically the same, except that package should just do that step. But maybe I’m just doing it wrong.

[solvingj]

Yes, looks good!