Carthage: Cartfile support for --no-use-binaries per dependency

[scottrhoyt]

It would be great to be able to specify in your Cartfile to not use binary framework downloads on a per-dependency basis. This would greatly aid during swift language transitions when libraries are built with different swift versions.

[scottrhoyt]

This is becoming more of an issue for us because unfortunately some commercial vendors are releasing binary-only carthage support, so if I use carthage to manage these dependencies --no-use-binaries is out of the question. However, there are still some libraries (like KeychainAccess) that haven't had a binary released with the latest Swift version so they necessitate --no-use-binaries.

Our workaround right now is to manually manage the binary-only dependency and --no-use-binaries for carthage. This results in double inconvenience. This feature would help users manage the pain of some of these unfortunate situations.

[pocket7878]

@scottrhoyt I have same problem..
And I just hacked up my little command to manage no-use-binaries for each dependencies
(Very early development use at your own risk) .

https://github.com/pocket7878/Barca

[fruitcoder]

I have the exact same problem (also using KeychainAccess :)

[TofPlay]

Same for me. I have some component that I have to compile from sources and other commercial components that only provide the binary version.

[mdiep]

Someone is working on #1308, which will hopefully solve the actual problem people are having.

[TofPlay]

Great 😀

[scottrhoyt]

@mdiep Thanks! That will help with the specific problem introduced by binary-only frameworks.

However, there still remains the issue with modules being compiled with different versions of Swift. This will remain an issue until at least Swift 4.0 with hopefully a stable ABI. I think this feature could potentially save 1000s of build hours between now and then.

If it's an issue of resources, I might be able to take a look at submitting a PR.

[mdiep]

I'm more interested in #1354, since that would solve this automatically. Would you have an interest in pursuing that?

(I also think that'd be much easier from a programming perspective.)

[scottrhoyt]

This is being addressed by #1755 which should solve one of the root problems here.

[scottrhoyt]

After #1755 and #1760, the root problems of this issue are solved for me, so I am going to go ahead and close. Thanks everyone!