Issue with framework search paths

[paulyoung]

I'm experiencing the same issue that I described in thoughtbot/Argo#121

Specifically, I see the following warnings when building a project that depends on Ogra:

(null): Directory not found for option '-F/path/to/MyProject/Carthage/Checkouts/Ogra/Carthage/Build/Mac'

(null): Directory not found for option '-F/path/to/MyProject/Carthage/Checkouts/Ogra/Carthage/Build/iOS'

I'm not sure how to resolve this other than to add a workspace and add the projects of dependencies there (Argo). This is the approach I usually take.

I'd be happy to submit a pull request to make these changes.

[edwardaux]

Just so I understand the problem... your project has Ogra as a dependency using carthage, but when you run carthage update you use the --no-build flag. And then when your project gets built inside Xcode, I assume it then tries to build Ogra as a dependent project which then warns about the missing Carthage directory. Is that right?

Our of curiosity, why do you use the --no-build flag?

[paulyoung]

Sounds like you understand my problem.

Out of curiosity, why do you use the --no-build flag?

This is partly so I can add dependencies as submodules (via --use-submodules), make changes / fixes to those, and then push updates.

Carthage/Carthage#177 may help with that, but I was already using the same workflow with submodules before Carthage came along, and this way I can treat Carthage as a nice wrapper around them.

Also, apparently 3rd-party binary frameworks are tied to a specific version of Xcode and Swift.

Lastly, it's in part because of this issue; if I use pre-built binaries, consumers of my framework with get warnings in the same way I am here.

[edwardaux]

Like you, I also use --use-submodules, however, I must admit I never use --no-build. For the dependencies that I am not editing, I just drag in the built framework from Carthage/Build/Mac, but for the dependencies that I am also editing, I tend to drag in the project from Carthage/Checkouts, add it as a Target Dependency and it just gets built as part of the normal Xcode build/link process.

I've just realised I would never see the warning because, even though I'm re-compiling my editable dependencies outside of the carthage build process, the Carthage/Build/Mac folder (and the releveant sub-folder symlinks) have already been created when I ran the original carthage update.

[paulyoung]

@edwardaux I was wondering if we could arrive at a resolution here either way.

If I were to submit a pull request with the relevant changes to support it, would you be opposed to using the --no-build flag from now?

[edwardaux]

I'm curious what changes would be in your PR. ie. I'm not sure what you'd change to fix it.

[edwardaux]

Thanks @paulyoung. I will give it a crack today... it takes a bit of time for me to test because my main use case is convoluted: the Mac app (XXX) that I'm building embeds a common Framework (XXXFramework) that embeds Ogra that embeds Argo.

[paulyoung]

That sounds similar to what I'm doing.

[edwardaux]

Still trying to get some time to look at your PR, but I was wondering if something as simple (dumb?) as checking in an empty folder called Carthage/Build/Mac would be sufficient?

[paulyoung]

That would prevent the warning but it would need to be done for every project that depends on Ogra in this way.

[edwardaux]

Just to be clear, I was suggesting that that directory hierarchy be checked into the Ogra project. For example, your error message was:

(null): Directory not found for option '-F/path/to/MyProject/Carthage/Checkouts/Ogra/Carthage/Build/Mac'

The way I read that error message, is that it is looking the checked-out Ogra/Carthage/Build/Mac directory. If I created the directories under Ogra's Carthage/Build/Mac directory, wouldn't that mean they exist and the warning goes away?

Don't get me wrong... I'm happy to dig into your PR. I'm just making sure I've really understood the problem :)

[paulyoung]

I see! My mistake.

I suppose that would work, but doesn't that directory get populated with dependencies?

The Carthage/Build directory is currently ignored, so I think the .gitignore file would need to change to something like:

Carthage/Build/*
!Carthage/Build/iOS/.gitkeep
!Carthage/Build/Mac/.gitkeep

You'd need to add a .gitkeep file or similar to any empty directory that you'd want to commit, since git ignores empty directories.

[edwardaux]

@paulyoung, sorry for taking so long to get back to you. I've finally had a chance to look at your PR (thanks!).

My concern is that we're introducing changes that mean we're prescribing how people have to use Ogra just to silence a non-destructive warning for the set of --no-build users.

I'm definitely leaning toward a solution that silences the warning. Is there any chance you could verify whether touching an empty Carthage/Build/Mac (and iOS) directory does indeed solve your problem?

[paulyoung]

My concern is that we're introducing changes that mean we're prescribing how people have to use Ogra

I think this should only affect how people develop Ogra, and everything else stays the same.

Is there any chance you could verify whether touching an empty Carthage/Build/Mac (and iOS) directory does indeed solve your problem?

I'm pretty sure it does, but I'll confirm.

[paulyoung]

mkdir -p Carthage/Checkouts/Ogra/Carthage/Build/iOS silenced the warning in a project I'm working on right now.

[edwardaux]

Just letting you know I haven't forgotten you 😄 You'd think that putting a .gitkeep file in a directory would be the simplest thing ever, wouldn't you? Turns out that if I add those files, then when I run carthage update, I get the following lovely stacktrace:

~/dev/Ogra> carthage update
*** Fetching Argo
*** Checking out Argo at "v2.1.0"
2015-11-04 20:34:16.826 carthage[62632:5101892] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'working directory doesn't exist.'
*** First throw call stack:
(
    0   CoreFoundation                      0x00007fff994d2e32 __exceptionPreprocess + 178
    1   libobjc.A.dylib                     0x00007fff925bcdd4 objc_exception_throw + 48
    2   CoreFoundation                      0x00007fff9953965d +[NSException raise:format:] + 205
    3   Foundation                          0x00007fff8ed8852b -[NSConcreteTask launchWithDictionary:] + 620
    4   ReactiveTask                        0x00000001099a39e5 _TFFFF12ReactiveTask10launchTaskFVS_15TaskDescriptionGV13ReactiveCocoa14SignalProducerGOS_9TaskEventCSo6NSData_OS_17ReactiveTaskError_U_FTGVSs6SinkOfGOS1_5EventGS3_S4__S5___CS1_19CompositeDisposable_T_U0_FTCS_P33_8622FA0C3FE9071537A42FE3BB905E344PipeS9__GS2_GS3_S4__S5__U_FTGS6_GS7_GS3_S4__S5___S8__T_ + 1253
    5   ReactiveTask                        0x000000010999d42b _TPA__TFFFF12ReactiveTask10launchTaskFVS_15TaskDescriptionGV13ReactiveCocoa14SignalProducerGOS_9TaskEventCSo6NSData_OS_17ReactiveTaskError_U_FTGVSs6SinkOfGOS1_5EventGS3_S4__S5___CS1_19CompositeDisposable_T_U0_FTCS_P33_8622FA0C3FE9071537A42FE3BB905E344PipeS9__GS2_GS3_S4__S5__U_FTGS6_GS7_GS3_S4__S5___S8__T_ + 251
    6   ReactiveCocoa                       0x000000010986111e _TFV13ReactiveCocoa14SignalProducer15startWithSignalU_S_9ErrorType__fGS0_Q_Q0__FFTGCS_6SignalQ_Q0__PS_10Disposable__T_T_ + 1086
    7   ReactiveCocoa                       0x0000000109881c2e _TPA__TFFFF13ReactiveCocoaP33_BB0E5F533EEE68215FAAD3E87E37BD995mergeU_S_9ErrorType__FGVS_14SignalProducerGS1_Q_Q0
... skipping a million lines of ReactiveCocoa nonsense ...

Through much trial and error, I found that if I remove the Argo submodule (ie. Carthage/Checkouts/Argo) and commit, then that shuts carthage up. However, it doesn't end there because if I use carthage update --use-submodules (my preferred approach), git complains that my workspace is dirty due to the newly added submodule. 😡

Anyway, I'm trying to get to the bottom of the ridiculous stack trace above. Bear with me.

[paulyoung]

Which version of Carthage are you using? I was getting errors like that a couple of versions back.

[edwardaux]

I was using 0.9.1 (which was also giving me some grief when I was testing to make sure that --no-use-binaries worked. I've since upgraded to 0.9.4 and it also gives me the above error.

[paulyoung]

Might be worth discussing the issue here Carthage/Carthage#678 (comment) since .gitkeep was specifically mentioned as a possible workaround.

[paulyoung]

@edwardaux any update on this?

[edwardaux]

Unfortunately not. I spent hours and hours trying to figure out why Carthage falls in a heap, and unfortunately no-one has been able to shed any light on my post in the Carthage issue referenced above.

However, I just noticed that Carthage has advanced a couple of versions. It is now at 0.11, and I had been trying at 0.9.4. Let me try tonight and see if that helps at all.

[edwardaux]

Well, actually... upgrading to carthage 0.11 seems to have fixed it. I'd be interested to see what happens if you reference my build_dot_files branch and see if it works for you.

[paulyoung]

Sorry for the delay on this. We've been focused on other things but this is definitely something we still want to resolve.

[edwardaux]

Totally understand. No rush.

[nickvelloff]

@edwardaux Hi. Issue still exists. Branch is no longer compatible with Argo to test.