Okay, so I see you have added
--prefer-dynamic, and you have enabled processing of
.automatic in several places. (I think it would be better to resolve early whether to divert it into
.dynamic mode and then let it simply flow through all the same code branches as the explicit options, but we can get to that later.)
It is not yet clear to me what the precise intended meaning of
--prefer-dynamic is. What is supposed to be dynamic?
- Are the toolchain libraries dynamic?
[Jon] By toolchain libraries, do you mean the core libraries like "libswiftCore.so"? Or something else?
- Are dependency products dynamic? All of them, or just conjunction nodes where it would be useful?
[Jon] I think I've made all the dependencies dynamic (I'll check this). This was my intention at least - for my use case, I want most things to be dynamic libraries. e.g. if:
- processA uses modA which uses modC
- processB uses modB which uses modC
then I do want all of modA, modB and modC to be compiled as dynamic libraries.
- Should it split
.automatic libraries into targets for more fine‐grained heuristics?
[Jon] Think I need to think about this further. I confess that certainly when I started on the changes, I found the distinction between products and targets unclear; I think I understand it a little better now.
- What about libraries in the same package?
[Jon] Generally I think they should result in a separate .so for each library listed in the products; the question below on "inter‐module optimization" might affect this I guess.
Some other important questions:
- Should it (or a companion flag) override explicit
[Jon] Not something I'd considered, but certainly a possibility. Do you have any feel for how often you've seen ".static" used, rather than leaving it unspecified?
- What happens when an explicit
.static ends up in two
.dynamic libraries linked into the same executable?
[Jon] I think this should be OK - but I think its definitely worth explicitly trying this to find out - I will do so and report back.
- How does this interplay with inter‐module optimization?
[Jon] I'm relatively new to Swift, so may not be best placed to answer this But yes, I think it will have an effect on e.g. "@inlineable"
Speaking personally, I'd accept that there would be tradeoffs like this for dynamic linking, but:
- It should definitely be documented
- It might point towards having different 'modes' for e.g. one .so per package, vs multiple .so's per package - though this might end up being more pain to support
- How much of this would be better as heuristics improvements for the default instead of an explicit option?
[Jon] I did consider this - particularly as it looks like you always get the static library made available as well as the dynamic library artefact. I'd be nervous of changing the default behaviour myself due to a lack of Swift experience.
- Are we in over our heads and all we really wanted is to produce a
.a for a top‐level
.automatic library that we then expect to use outside of SwiftPM?
[Jon] For my use case I did definitely want more than just a top-level .so, due to the wider system I'm looking to integrate with - but I'm certainly open to input from others here.
The answers to these questions affect whether it will need to go through the full evolution process and in turn, how much work would be ahead of you.