search

mattgallagher / CwlSignal

A Swift framework for reactive programming.
ISC License
303 stars 33 forks source link

Carthage Support #3

Closed Ashton-W closed 7 years ago

Ashton-W commented 7 years ago

Pleased to say CwlSignal supports Carthage already.

However, it generates the following binaries:

Carthage/
└── Build
    ├── Mac
    │   ├── CwlCatchException.framework
    │   ├── CwlCatchException.framework.dSYM
    │   ├── CwlPreconditionTesting.framework
    │   ├── CwlPreconditionTesting.framework.dSYM
    │   ├── CwlSignal.framework
    │   ├── CwlSignal.framework.dSYM
    │   ├── CwlUtils.framework
    │   └── CwlUtils.framework.dSYM
    ├── iOS
    │   ├── CwlCatchException.framework
    │   ├── CwlCatchException.framework.dSYM
    │   ├── CwlPreconditionTesting.framework
    │   ├── CwlPreconditionTesting.framework.dSYM
    │   ├── CwlSignal.framework
    │   ├── CwlSignal.framework.dSYM
    │   ├── CwlUtils.framework
    │   └── CwlUtils.framework.dSYM
    └── tvOS
        ├── CwlPreconditionTesting.framework
        └── CwlPreconditionTesting.framework.dSYM

Unfortunately Carthage will build the schemes in all projects it finds, including the CwlUtils. Users of this framework only actually need CwlSignal.framework.

We could document this fact for Carthage users. I don't know of a way to control what Cathage builds. Thoughts?

mattgallagher commented 7 years ago

Theoretically, I could change the linked CwlUtils subtree over to a dedicated branch that omits the CwlUtils.xcodeproj file and the CwlPrecondition subtree (and by extension CwlCatchException subtree) but I'd need to create such a branch keep it up-to-date over time. I'm hesitant because it's a non-zero amount of maintenance but it wouldn't be impossible.

However, I think it might be a lot easier just to put a note in the ReadMe file.

Ashton-W commented 7 years ago

I think another option would be to pull the them down with Carthage (or a directory structure that looks like it), as it will ignore dependencies it pulled down itself.

mattgallagher commented 7 years ago

That's the scenario I was trying to avoid as it places a git submodule management burden onto non-Carthage users, versus the current subtree arrangement which is ready-to-use immediately on pulling of the CwlSignal repository.

Ashton-W commented 7 years ago

I mean use Carthage (or mimick it) with checked in sources, not sub modules. I'll try it out locally

Ashton-W commented 7 years ago

Well it works. Moving CwlUtils/ to Carthage/Checkouts/CwlUtils/ makes Carthage ignore it. The command I'm using is carthage build --no-skip-current by the way.

Carthage/
├── Build
│   ├── Mac
│   │   ├── CwlSignal.framework
│   │   └── CwlSignal.framework.dSYM
│   └── iOS
│       ├── CwlSignal.framework
│       └── CwlSignal.framework.dSYM
└── Checkouts
    └── CwlUtils
        ├── CwlPreconditionTesting
        ├── CwlUtils
        ├── CwlUtils.xcodeproj
        ├── CwlUtilsTests
        ├── CwlUtils_iOSHarness
        ├── CwlUtils_iOSHarnessUITests
        ├── CwlUtils_macOSHarness
        ├── CwlUtils_macOSHarnessUITests
        └── README.md

🤕 Whether this is worth doing or not..

https://github.com/Ashton-W/CwlSignal/tree/aw-carthage-workaround

mattgallagher commented 7 years ago

Carthage build support is now fully supported (since 2.0.0-beta.18 or something).