-
Notifications
You must be signed in to change notification settings - Fork 993
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
[feature] Symlink Imports #7030
Comments
Hi! First of all, I would think twice if using If you can avoid using imports, then Are imports really necessary in your scenario? |
We use We have many runtime dependencies such as shared libraries, runtime-loaded libraries, config-files, and even executables (yes, there are some legacy decisions that have stuck with us). As stated in the document, "In Windows and OSX, the simplest approach is to copy the shared libraries to the executable folder, so they are found by the executable, without having to modify the path." This is the approach we've taken, and it's fit our needs precisely. Before we switched to Conan for package management, our CMake build system actually had some custom logic to copy the shared libraries of dependencies in order to automatically run software tests on Windows. I was very happy to see Conan had thought out a better way to handle that exact need with So, we extensively use |
Hi! I'm still thinking about this. I know executing things from CMake is a little bit hard when you need shared libraries, this is an issue we have faced in some of our examples (conan-io/examples#17) and also in the For the general use-case, Adding For workspaces, it will continue to be a problem, but the workspaces feature is something we need to work again. Let's add |
The imports() method has been made legacy in Conan 1.X by explicit copy() in generate() and removed in Conan 2.0. Closing this ticket, please create new tickets as necessary, thanks! |
When using an editable package, if that package is built as a shared library, then imports of the runtime binaries will become stale. This requires
conan imports
to be run manually whenever the editable is rebuilt, against the stated intention of the editables feature.If editable imports were made as symlinks rather than copies, that would be sufficient in most cases to avoid running
conan imports
regularly.A proposed feature would be to include a
--symlink
option to theconan imports
command (and expose this onconan install
as well).An alternative would be to automatically use symlinks for editable packages, if the environment supports them. This could eventually extend to even non-editable packages if desired.
A workaround was suggested in the channel on cpplang slack:
This is not desirable, as it requires adding to the conanfile.py of any package which might be worked on in this way. It also forces the use of a conanfile.py instead of a conanfile.txt.
The text was updated successfully, but these errors were encountered: