Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Build issues when using ReactiveCocoa and another Reactive framework. #332

Closed
Coneko opened this Issue Feb 18, 2013 · 11 comments

Comments

Projects
None yet
3 participants
Member

Coneko commented Feb 18, 2013

See jspahrsummers/xcconfigs#4.

This was brought to my attention by the fact that the magic subproject includes seems to randomly screw up the build process if you have a subproject that has a subproject that's the same as your main project.
In my case my project has both ReactiveCocoa and ReactiveCocoaIO as subprojects, and ReactiveCocoaIO has ReactiveCocoa as subproject.

Every once in a while the build fails because of redefinitions in RACBacktrace.h and I have to clear out the build intermediates directories and rebuild.

Owner

jspahrsummers commented Feb 18, 2013

ReactiveCocoaLayout has a similar issue. I "solved" the problem by basically using Xcode workspaces instead. If your application is also using a workspace, Xcode does a better job of resolving the diamond dependencies.

Does setting up RCIO like RCL work?

Member

Coneko commented Feb 19, 2013

I haven't bothered with workspaces from when they drove me crazy because of rebuilding issues. They used to work great the first time I built, but if I made changes to the other projects in the workspace and rebuilt the main project's target which depended on them it wouldn't always rebuild the depending targets.

I'm not sure whether that was an issue with the automatic dependency resolving or I had set it up wrong myself, but I just went back to subprojects at the time.

I might try it again if it does work better in cases like this. Did you add RCL and RAC as explicit target dependencies or did you let Xcode figure it out?

Owner

jspahrsummers commented Feb 19, 2013

I used implicit dependencies for anything that's not a subproject, including RCL and RAC.

Member

Coneko commented Feb 20, 2013

Ah I see it now in ReactiveCocoa/ReactiveCocoaLayout#52.
I'm going to change how RCIO is set up to mirror that then. It might take a while because I'm going away for a bit.

@Coneko Coneko closed this Feb 20, 2013

Member

Coneko commented Mar 27, 2013

I set up RCIO to use a workspace, mimicking RCL, and everything worked fine.

Then while messing around I found out this leads to a problem: every framework that depends on RAC is going to link it statically in it's iOS target, which leads to duplicate symbols in apps using more than one.
So I went back and fixed that, but that requires adding RAC back as a subproject in the RCIO project since you can't add targets as dependencies otherwise, and I need RAC to build the library even though I don't link it so I can import the headers with the correct includes (I could add the RAC headers in the header search paths, but that still wouldn't allow me to #include <ReactiveCocoa/EXTScope.h>).

I think I managed to work around everything, but it still needs disabling ALWAYS_SEARCH_USER_PATHS because of RACBacktrace.h (see jspahrsummers/xcconfigs#4, jspahrsummers/libextobjc#23).

@Coneko Coneko reopened this Mar 27, 2013

Owner

jspahrsummers commented Mar 27, 2013

Yeah, the linking situation is shitty. How'd you work around the duplicate symbols?

Member

Coneko commented Mar 27, 2013

I don't link RAC in RCIO at all.
This means that the final user of the library will have to link in both RCIO and RAC.
If you used frameworks you'd have to link in both of them as well, so it works out in the end in this particular case, but it's not a perfect solution for all cases, since if you did that the final user would have to link with lots and lots of libraries (suppose someone made another library that used Archimedes, and someone wanted to use both libraries in their app).

There's some discussion out there about this whole issue, since with more and more open source iOS libraries and with a lot of "libraries" that tell you to add the library source files to your project it all gets out of hand really fast.

Owner

jspahrsummers commented Mar 27, 2013

This is ostensibly one of the use cases that CocoaPods solves. I'm not super interested in it, since I primarily do Mac development (where you can just dynamically link things and avoid a lot of problems), but it might be worth looking into for your project.

Member

Coneko commented Mar 27, 2013

Yes, I've been meaning to try it out but something else always pops up.
Since it's going to be fine once #402 gets merged in I'll put it off again for now.

Owner

joshaber commented Mar 28, 2013

Can this be closed now that #402 is in?

Member

Coneko commented Mar 28, 2013

Yep. I rambled a lot and the discussion ended up everywhere, but this issue was only about RACBacktrace.h being imported twice, and the new configuration solves it.

@Coneko Coneko closed this Mar 28, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment