Issue with framework search paths

[paulyoung]

I keep running into an issue where frameworks I depend on have Carthage/Build/Mac and Carthage/Build/iOS in their framework search paths, which causes warnings when building my projects (I'm using the --no-build, --use-submodules, and --no-use-binaries flags).

Removing them is not an option for the framework author as it causes their build to fail for the project.

Some examples of this are thoughtbot/Argo#121 and edwardaux/Ogra#4.

The solution so far has been for those frameworks to add the projects of their dependencies to a workspace and use submodules.

This is how I usually deal with dependencies but I don't want to dictate how others should structure their projects if there is another way.

Is there a recommended way to solve this other than what I've described? If so, could it be added or made more prominent in the README / documentation?

[mdiep]

Just to be clear: everything works, Xcode just warns you that the Carthage/Build/Mac directory doesn't exist.

I don't think that there's really anything to be done here. The warning is annoying. Personally, I think it's ridiculous that Xcode warns you in this case without any way to silence it. But it works.

There are probably a few workarounds:

1. Just create that directory (Carthage could maybe do this for you)
2. Have each dependency copy the frameworks into a known-to-exist location and use that as the search dir
3. Have each dependency use a workspace and add the .xcodeproj for each dependency (that's usually what we do)

Realistically, I think fixing a warning is going to be a low priority.

[ikesyo]

1. Just create that directory (Carthage could maybe do this for you)

It could maybe be done by adding a .gitkeep or another empty file to Carthage/Build/Mac or Carthage/Build/iOS in that repositories and don't ignore the file, I think.

[paulyoung]

Thanks for sharing. Good to know I'm not doing something wrong at least.

[edwardaux]

So, I'm trying this technique to resolve edwardaux/Ogra#4. The setup is as follows: my project (Ogra) embeds another project (Argo) using carthage. You can reproduce by using the following commands:

cd /tmp
git clone -b build_dot_files https://github.com/edwardaux/Ogra
cd Ogra
carthage update

This branch contains two changes: 1) add an empty .gitkeep file in the Mac, iOS, and watchOS directories, 2) add those files to .gitignore so that they get checked in. When you run those commands, you will get the following lovely stacktrace:

/tmp/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                      0x00007fff96728e32 __exceptionPreprocess + 178
1   libobjc.A.dylib                     0x00007fff8f812dd4 objc_exception_throw + 48
2   CoreFoundation                      0x00007fff9678f65d +[NSException raise:format:] + 205
3   Foundation                          0x00007fff8bfde52b -[NSConcreteTask launchWithDictionary:] + 620
4   ReactiveTask                        0x00000001020889e5 _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                        0x000000010208242b _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                       0x0000000101f4711e _TFV13ReactiveCocoa14SignalProducer15startWithSignalU_S_9ErrorType__fGS0_Q_Q0__FFTGCS_6SignalQ_Q0__PS_10Disposable__T_T_ + 1086
7   ReactiveCocoa                       0x0000000101f67c2e _TPA__TFFFF13ReactiveCocoaP33_BB0E5F533EEE68215FAAD3E87E37BD995mergeU_S_9ErrorType__FGVS_14SignalProducerGS1_Q_Q0__Q0__GS1_Q_Q0__U_FTGVSs6SinkOfGOS_5EventQ_Q0___CS_19CompositeDisposable_T_U0_FTGCS_6SignalGS1_Q_Q0__Q0__PS_10Disposable__T_U_FGS1_Q_Q0__T_ + 238
8   ReactiveCocoa                       0x0000000101f67cac _TPA__TTRG1_RPq0_P13ReactiveCocoa9ErrorType__XFo_oGVS_14SignalProducerq_q0___dT__XFo_iGS1_q_q0___iT__ + 60
9   ReactiveCocoa                       0x0000000101f7a0ed _TFZFO13ReactiveCocoa5Event4sinkU_S_9ErrorType__FMGS0_Q_Q0__FT5errorGSqFQ0_T__9completedGSqFT_T__11interruptedGSqFT_T__4nextGSqFQ_T___GVSs6SinkOfGS0_Q_Q0___U_FGS0_Q_Q0__T_ + 637
10  ReactiveCocoa                       0x0000000101f52151 _TPA__TFZFO13ReactiveCocoa5Event4sinkU_S_9ErrorType__FMGS0_Q_Q0__FT5errorGSqFQ0_T__9completedGSqFT_T__11interruptedGSqFT_T__4nextGSqFQ_T___GVSs6SinkOfGS0_Q_Q0___U_FGS0_Q_Q0__T_ + 225
11  ReactiveCocoa                       0x0000000101f797e8 _TPA__TFFVSs6SinkOfcU__FMGS_Q__USs8SinkType__FQ_GS_Qd___U_FQd__T_2152 + 72
12  ReactiveCocoa                       0x0000000101f81ae5 _TFFC13ReactiveCocoa6SignalcU_S_9ErrorType__FMGS0_Q_Q0__FFGVSs6SinkOfGOS_5EventQ_Q0___GSqPS_10Disposable__GS0_Q_Q0__U_FGS3_Q_Q0__T_ + 1365
13  ReactiveCocoa                       0x0000000101f9bbcb _TFFV13ReactiveCocoa14SignalProducer15startWithSignalU_S_9ErrorType__FGS0_Q_Q0__FFTGCS_6SignalQ_Q0__PS_10Disposable__T_T_U0_FGOS_5EventQ_Q0__T_ + 155
14  ReactiveCocoa                       0x0000000101f5de71 _TPA__TFFV13ReactiveCocoa14SignalProducer15startWithSignalU_S_9ErrorType__FGS0_Q_Q0__FFTGCS_6SignalQ_Q0__PS_10Disposable__T_T_U0_FGOS_5EventQ_Q0__T_586 + 113
15  ReactiveCocoa                       0x0000000101f797e8 _TPA__TFFVSs6SinkOfcU__FMGS_Q__USs8SinkType__FQ_GS_Qd___U_FQd__T_2152 + 72
16  ReactiveCocoa                       0x0000000101f81ae5 _TFFC13ReactiveCocoa6SignalcU_S_9ErrorType__FMGS0_Q_Q0__FFGVSs6SinkOfGOS_5EventQ_Q0___GSqPS_10Disposable__GS0_Q_Q0__U_FGS3_Q_Q0__T_ + 1365
17  ReactiveCocoa                       0x0000000101f82f74 _TFFFF13ReactiveCocoa3mapU__S_9ErrorType__FFQ_Q0_FGCS_6SignalQ_Q1__GS1_Q0_Q1__U_FGS1_Q_Q1__GS1_Q0_Q1__U_FGVSs6SinkOfGOS_5EventQ0_Q1___GSqPS_10Disposable__U_FGS3_Q_Q1__T_ + 196
18  ReactiveCocoa                       0x0000000101f6fd30 _TPA__TFFFF13ReactiveCocoa3mapU__S_9ErrorType__FFQ_Q0_FGCS_6SignalQ_Q1__GS1_Q0_Q1__U_FGS1_Q_Q1__GS1_Q0_Q1__U_FGVSs6SinkOfGOS_5EventQ0_Q1___GSqPS_10Disposable__U_FGS3_Q_Q1__T_ + 144
19  ReactiveCocoa                       0x0000000101f797e8 _TPA__TFFVSs6SinkOfcU__FMGS_Q__USs8SinkType__FQ_GS_Qd___U_FQd__T_2152 + 72
20  ReactiveCocoa                       0x0000000101f81ae5 _TFFC13ReactiveCocoa6SignalcU_S_9ErrorType__FMGS0_Q_Q0__FFGVSs6SinkOfGOS_5EventQ_Q0___GSqPS_10Disposable__GS0_Q_Q0__U_FGS3_Q_Q0__T_ + 1365
21  ReactiveCocoa                       0x0000000101f9bbcb _TFFV13ReactiveCocoa14SignalProducer15startWithSignalU_S_9ErrorType__FGS0_Q_Q0__FFTGCS_6SignalQ_Q0__PS_10Disposable__T_T_U0_FGOS_5EventQ_Q0__T_ + 155
22  ReactiveCocoa                       0x0000000101f5de71 _TPA__TFFV13ReactiveCocoa14SignalProducer15startWithSignalU_S_9ErrorType__FGS0_Q_Q0__FFTGCS_6SignalQ_Q0__PS_10Disposable__T_T_U0_FGOS_5EventQ_Q0__T_586 + 113
... skipping a million lines of ReactiveCocoa stack frames ...

Interestingly, through much trial and error, I found that if I remove the Argo submodule (ie. Carthage/Checkouts/Argo) and commit, then that stops the error above. However, it doesn't solve my real problem because if I use carthage update --use-submodules (my preferred approach), git complains that my workspace is dirty due to the newly added submodule.

Any thoughts on what might cause the stack trace above? Thanks.

[ikesyo]

It seems that this can be closed now: edwardaux/Ogra#4 (comment)

[paulyoung]

I believe that comment was only referring to the error/stack trace in the previous message.

I've yet to confirm if the workaround on the build_dot_files branch of Ogra addresses the warning in my original comment.

[edwardaux]

Just confirming that edwardaux/Ogra#4 (comment) was indeed only confirming that the stack trace I referenced in #678 (comment) was resolved.

Not sure what the long-term solution might (if there is one?). Xcode is the guy that is emitting the spurious warning. As far as I can tell, two possible solutions are:

a) the project creates the directories (this is what I was exploring for Ogra)
b) carthage adds a flag to create the empty directories (not sure how high on the list of priorities this would be though)