On Mar 4, 2014, at 14:59, Adam R. Maxwell wrote: > You may need to set Xcode up to put products in a specific location. I'm not > using Xcode 3, so can't say for sure. Your solution sounds wrong. > >> On Mar 3, 2014, at 23:31, Reto Stöckli <reto.stoc...@gmail.com> wrote: >> >> Colin and Adam >> >> I managed to compile most the current SVN version of Bibdesk with OSX 10.6 & >> Xcode 3.2.6. However, why are header locations in some of the source files >> wrong? Am I missing something or is the SVN version broken? >> >> Could you quickly check in your code, for instance: >> >> 1. BDSKAppController.m contains: #import <Sparkle/Sparkle.h> >> but the header is located in: vendorsrc/andymatuschak/Sparkle/Sparkle.h >> --> can be solved by adding a recursive default header search path to XCode >> >> 2. BDSKNotesSearchIndex.m contains: #import <SkimNotesBase/SkimNotesBase.h> >> But the header is located in: SkimNotes/SkimNotesBase.h >> --> can only be solved by editing BDSKNotesSearchIndex.m >> >> 3. vendorsrc/indexdata/yaz/objc/ZOOMConnection.h contains: #import >> <yaz/ZOOMResultSet.h> >> But the header is located in the same directory: ZOOMResultSet.h >> --> can only be solved by editing ZOOMConnection.h >> >> There are several more, but please check these here first. >> >> Reto
These are all right. The import with angles means that it looks for the headers in the frameworks, and that's where they are. However, you need to build the frameworks in the same build location as the app, otherwise it won't find those frameworks. Xcode 4 & 5 do this normally automatically, but for Xcode 4 you have to set up a customized build location (in the Build preferences.) It is possible to add search paths, but to the build frameworks (not the originals), in fact that's what we used to do, but this leads to tons of warnings when you don't use them (and they don't exist), especially on Xcode 4 & 5. So they're commented out in Skim-App.xcconfig. You could uncomment that line in your local version, as an alternative solution. But I'd recommend using a custom build location, that makes more sense anyway, because it does not mess up the source directories. Christiaan >> >>> On Feb 28, 2014, at 5:33 PM, Smith, Colin wrote: >>> >>> Hi Reto, >>> >>> I don't know. You'd have to ask on the developer e-mail list. >>> >>> Cheers, >>> >>> Colin >>> >>> Sent from my iPhone >>> >>>> On Feb 28, 2014, at 17:25, "Reto Stöckli" <reto.stoc...@gmail.com> wrote: >>>> >>>> Colin >>>> >>>> Are any of the Bibdesk developers still using OSX 10.6 and X-Code 3.x? >>>> My first tries with this "outdated" system yielded quite many unresolved >>>> dependencies (not just on the SDK version, this was the easy one). >>>> >>>> Reto >> > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Bibdesk-develop mailing list > Bibdesk-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
