-
Notifications
You must be signed in to change notification settings - Fork 22
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
Make status
target always shows outdated
#100
Comments
Case in point:
The |
One thing which would solve (A) is the use of lockfiles with |
It works like this: make LOCKFILE_SOURCE=../conanfile.py all when you are in sub-directory and you want to use some other profile for dependency resolution etc. The lockfile source can also be used for the status target: make LOCKFILE_SOURCE=../conanfile.py status This will result in a different answer to the case where no lockfile is specified. This partially resolves issue #100.
The commit referenced above solves (1) by adding |
It works like this: make LOCKFILE_SOURCE=../conanfile.py all when you are in sub-directory and you want to use some other profile for dependency resolution etc. The lockfile source can also be used for the status target: make LOCKFILE_SOURCE=../conanfile.py status This will result in a different answer to the case where no lockfile is specified. This partially resolves issue #100.
It works like this: make LOCKFILE_SOURCE=../conanfile.py all when you are in sub-directory and you want to use some other profile for dependency resolution etc. The lockfile source can also be used for the status target: make LOCKFILE_SOURCE=../conanfile.py status This will result in a different answer to the case where no lockfile is specified. This partially resolves issue #100.
It works like this: make LOCKFILE_SOURCE=../conanfile.py all when you are in sub-directory and you want to use some other profile for dependency resolution etc. The lockfile source can also be used for the status target: make LOCKFILE_SOURCE=../conanfile.py status This will result in a different answer to the case where no lockfile is specified. This partially resolves issue #100.
It works like this: make LOCKFILE_SOURCE=../conanfile.py all when you are in sub-directory and you want to use some other profile for dependency resolution etc. The lockfile source can also be used for the status target: make LOCKFILE_SOURCE=../conanfile.py status This will result in a different answer to the case where no lockfile is specified. This partially resolves issue #100.
status
target always shows outdated
I realize that
make status
says that it's approximate, because it compares the package age with all the files in the package directory, but this is causing confusion for our users.There are several issues at play here though regarding
ok
vsoutdated
:make status
may not represent the package you're interested in, since there might be one linked toboost/1.68
that is ancient but another that is linked toboost/1.78.0
that is up-to-date. How are we even to know which configuration the user is interested in?make status
may not be accurate, since we modified a file that is not contributing to the package (eg. README), making it look as though the package is outdated, when it is not.Really, the whole point of
make status
is the following:A. Ensure that I don't forget to export changes to recipe or sources.
B. Ensure that I don't forget to build a package if it's outdated.
C. Tell me if this package is in editable mode or not.
It would be easy enough to solve problems (1) and (2) with
cloe-launch
. However, cloe-launch cannot by nature address (A) and addressing (C) doesn't make much sense for cloe-launch.Proposed solution:
ok?
andoutdated?
in output frommake status
cloe-launch
to check if package is out-of-date (how?)cloe-launch
when a user is using out-of-date packagesThis last point would fix the unreadable output from
cloe-launch
when the requirements are not available.The text was updated successfully, but these errors were encountered: