|
11 | 11 | //! should be used when linking each output type requested in this session. This |
12 | 12 | //! generally follows this set of rules: |
13 | 13 | //! |
14 | | -//! 1. Each library must appear exactly once in the output. |
15 | | -//! 2. Each rlib contains only one library (it's just an object file) |
16 | | -//! 3. Each dylib can contain more than one library (due to static linking), |
17 | | -//! and can also bring in many dynamic dependencies. |
| 14 | +//! 1. Each library must appear exactly once in the output. |
| 15 | +//! 2. Each rlib contains only one library (it's just an object file) |
| 16 | +//! 3. Each dylib can contain more than one library (due to static linking), |
| 17 | +//! and can also bring in many dynamic dependencies. |
18 | 18 | //! |
19 | 19 | //! With these constraints in mind, it's generally a very difficult problem to |
20 | 20 | //! find a solution that's not "all rlibs" or "all dylibs". I have suspicions |
21 | 21 | //! that NP-ness may come into the picture here... |
22 | 22 | //! |
23 | 23 | //! The current selection algorithm below looks mostly similar to: |
24 | 24 | //! |
25 | | -//! 1. If static linking is required, then require all upstream dependencies |
26 | | -//! to be available as rlibs. If not, generate an error. |
27 | | -//! 2. If static linking is requested (generating an executable), then |
28 | | -//! attempt to use all upstream dependencies as rlibs. If any are not |
29 | | -//! found, bail out and continue to step 3. |
30 | | -//! 3. Static linking has failed, at least one library must be dynamically |
31 | | -//! linked. Apply a heuristic by greedily maximizing the number of |
32 | | -//! dynamically linked libraries. |
33 | | -//! 4. Each upstream dependency available as a dynamic library is |
34 | | -//! registered. The dependencies all propagate, adding to a map. It is |
35 | | -//! possible for a dylib to add a static library as a dependency, but it |
36 | | -//! is illegal for two dylibs to add the same static library as a |
37 | | -//! dependency. The same dylib can be added twice. Additionally, it is |
38 | | -//! illegal to add a static dependency when it was previously found as a |
39 | | -//! dylib (and vice versa) |
40 | | -//! 5. After all dynamic dependencies have been traversed, re-traverse the |
41 | | -//! remaining dependencies and add them statically (if they haven't been |
42 | | -//! added already). |
| 25 | +//! 1. If static linking is required, then require all upstream dependencies |
| 26 | +//! to be available as rlibs. If not, generate an error. |
| 27 | +//! 2. If static linking is requested (generating an executable), then |
| 28 | +//! attempt to use all upstream dependencies as rlibs. If any are not |
| 29 | +//! found, bail out and continue to step 3. |
| 30 | +//! 3. Static linking has failed, at least one library must be dynamically |
| 31 | +//! linked. Apply a heuristic by greedily maximizing the number of |
| 32 | +//! dynamically linked libraries. |
| 33 | +//! 4. Each upstream dependency available as a dynamic library is |
| 34 | +//! registered. The dependencies all propagate, adding to a map. It is |
| 35 | +//! possible for a dylib to add a static library as a dependency, but it |
| 36 | +//! is illegal for two dylibs to add the same static library as a |
| 37 | +//! dependency. The same dylib can be added twice. Additionally, it is |
| 38 | +//! illegal to add a static dependency when it was previously found as a |
| 39 | +//! dylib (and vice versa) |
| 40 | +//! 5. After all dynamic dependencies have been traversed, re-traverse the |
| 41 | +//! remaining dependencies and add them statically (if they haven't been |
| 42 | +//! added already). |
43 | 43 | //! |
44 | 44 | //! While not perfect, this algorithm should help support use-cases such as leaf |
45 | 45 | //! dependencies being static while the larger tree of inner dependencies are |
|
0 commit comments