@@ -7,10 +7,10 @@ Packages in editable mode
7
7
8
8
This is an **experimental ** feature subject to breaking changes in future releases.
9
9
10
- When working in big projects with several functionalities interconnected it is recomended to avoid
11
- the one-and-only huge project approach in favor of several libraries each one of them specialized
10
+ When working in big projects with several functionalities interconnected it is recommended to avoid
11
+ the one-and-only huge project approach in favor of several libraries, each one specialized
12
12
in a set of common tasks, even maintained by dedicated teams. This approach helps to isolate
13
- and reuse code, helps with compiling times and reduces the likelihood of including files that
13
+ and reusing code helps with compiling times and reduces the likelihood of including files that
14
14
not correspond to the API of the required library.
15
15
16
16
Nevertheless, in some case, it is useful to work in several libraries at the same time and see how
@@ -21,16 +21,14 @@ get the changes ready for a consumer library, it is needed the :command:`conan c
21
21
actually trigger a build to generate the binaries in the cache or to run :command: `conan export-pkg `
22
22
to copy locally built artifacts into the conan cache and make them available to consumers.
23
23
24
- What about if you just can tell Conan where to find the headers and the artifacts ready for
25
- consumption in your local working directory? No need to package, just tell Conan to use those
26
- artifacts you have just generated with your IDE, sounds good? This is what the feature
27
- *editable packages * will do for you.
24
+ With the editable packages, you can tell Conan where to find the headers and the artifacts ready for
25
+ consumption in your local working directory. There is no need to package.
28
26
29
27
Let's see this feature over an example where a developer is creating a ``CoolApp `` but at the same
30
- time they wants to work on ``cool/version@user/dev `` library which is tightly coupled to the app.
28
+ time they want to work on ``cool/version@user/dev `` library which is tightly coupled to the app.
31
29
32
30
The package ``cool/version@user/dev `` is already working, the developer has the sources in a
33
- local folder, they is using whatever method to build and develop locally and can perform
31
+ local folder and they are using whatever method to build and develop locally and can perform
34
32
a :command: `conan create . cool/version@user/dev ` to create the package.
35
33
36
34
Also, there is a *conanfile.txt * (or a more complex recipe) for the application ``CoolApp `` that
@@ -47,14 +45,14 @@ working directory**:
47
45
.. code-block :: bash
48
46
49
47
$ conan editable add < path/to/local/dev/libcool> cool/version@user/dev
50
- # you could do cd <path/to/local/dev/libcool> && conan editable add . cool/version@user/dev
48
+ # you could do " cd <path/to/local/dev/libcool> && conan editable add . cool/version@user/dev"
51
49
52
50
53
- That is it. Now, every usage of ``cool/version@user/dev ``, by any other Conan package, or project
54
- will be redirected to the ``<path/to/local/dev/libcool> `` user folder, instead of using the package
51
+ That is it. Now, every usage of ``cool/version@user/dev ``, by any other Conan package or project,
52
+ will be redirected to the ``<path/to/local/dev/libcool> `` user folder instead of using the package
55
53
from the conan cache.
56
54
57
- Conan package recipes define a package "layout" in their ``package_info() `` methods. The default one,
55
+ The Conan package recipes define a package "layout" in their ``package_info() `` methods. The default one,
58
56
if nothing is specified is equivalent to:
59
57
60
58
.. code-block :: python
0 commit comments