Re: Project importing
Re: Project importing
- Subject: Re: Project importing
- From: Andreas Grosam <email@hidden>
- Date: Thu, 29 Mar 2012 20:42:27 +0200
On Mar 29, 2012, at 6:59 PM, Conrad Shultz wrote:
> On 3/29/12 9:49 AM, Quincey Morris wrote:
>> On Mar 29, 2012, at 08:38 , Dan Hopwood wrote:
>>
>>> I am trying to integrate a tool (core-plot) into an existing project,
>>> following their integration guide
>>> (http://code.google.com/p/core-plot/wiki/UsingCorePlotInApplications).
>>> The first step is:
>>>
>>> "Drag the CorePlot-CocoaTouch.xcodeproj file into your iPhone
>>> application's Xcode project."
>>>
>>> Well, this is where I fall down. I remember doing this in older
>>> versions of Xcode and it working fine but with Xcode 4.3.2 the project
>>> file shows up in the navigator but there is no expand arrow and no
>>> files associated with it.
>>>
>>> Is there another way of importing an external project so that it can
>>> be made a dependency?
>>
>> Yes. Create a workspace, and drag both your original project and the
>> library project into the workspace -- both at the top level, not one
>> within the other. Xcode understands that as a dependency configuration.
>
> +1, but a caveat is that I found that at least for me, with fairly
> plain-vanilla configurations, Xcode wouldn't find headers for import
> unless I manually added ${BUILT_PRODUCTS_DIR} to my user header search
> path (and have the headers copied into the build product).
That really depends on how you setup the library project. On iOS, this is a static library, and setting it up correctly, is a bit more elaborated than for frameworks on Mac OS X.
So, the somewhat elaborated way, is as follows:
Use a workspace and add/create all projects (into the top level).
In the static library project:
- Ensure that "public" headers are specified. Specify only those header that expose the API.
(Check the "Public" sub section in "Copy Headers" section in the "Build Phases" tab of the target editor)
- Set build setting "Public Headers Folder Path (PUBLIC_HEADERS_FOLDER_PATH) to <lib_name>, possibly $(TARGET_NAME) or a name that uniquely identifies the library project, example:
PUBLIC_HEADERS_FOLDER_PATH = MyLib
The name "MyLib" later equals the *prefix* in the qualified include directive, e.g. in your sources you include a public header:
#include "MyLib/myheader.h"
Note, the default is /usr/local/include - and not that appropriate for a static lib on iOS.
- Ensure build setting "Skip Install" (SKIPP_INSTALL) is set to YES:
SKIPP_INSTALL = YES
This is important, otherwise if you miss that, then archiving the final product will be impossible.
In the client project:
- Link against the static library, via Xcode UI "Link Binary With Libraries".
Once the static lib project is in the workspace you can find it easily under the Workspace folder.
Here, Xcode shows us two bugs:
1) if the binary of the static lib already exists when linking it to the main project, Xcode adds a spurious library search path to the build settings. Remove it (in build setting "Library Search Paths").
2) if the binary does not exist, Xcode confuses file paths and the entry in the "Link Binary With Libraries" and possibly in the Navigator pane, too, becomes red. I hope we can ignore it.
- Add a header search path for the public headers of the static library.
When building the static lib, the puplic headers of the static libraries will be copied into folder $(BUILT_PRODUCTS_DIR)/<lib_name>.
Since you want to use *qualified* include directives, e.g.
#include "MyLib/myheader.h"
you *add* the following Header search path: $(BUILT_PRODUCTS_DIR)
This will find the headers when building for Run, Debug, Profile and also for "Build For Archive - but fails when trying to perform Product -> Archive
Possibly a bug. In order to work around this issue, add the following path to the Header Search Paths:
$(OBJROOT)/UninstalledProducts
So, finally:
HEADER_SEARCH_PATHS = $(BUILT_PRODUCTS_DIR) $(OBJROOT)/UninstalledProducts possibly/other/path
Hope I didn't miss something important ;)
Regards
Andreas
>
> I'm sure there are other recommended ways to do this (especially that
> don't involve header copying), and I'd love to hear them. I'm still
> getting used to the whole Workspace concept.
>
>
> --
> Conrad Shultz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden