Apple

This works well for static libraries (why isn’t it in the user’s guide?) but not for dynamic libs. When I do this with my dynamic libs it issues a fullpath on the link line, and the path it gives the dynamic lib is that of my build product, not the path where the lib is built.

David Litwin

Chris Espinosa writes:

The best way to do this is to use a shared build folder between the project that builds the static library and the project that builds its clients. Both projects should have Debug and Release configurations (the names are arbitrary, but should be the same in each project).

When you build the static library's Debug configuration, it will build into $(SYMROOT)/Debug/mylib.a, and when you build Release, it will build into $(SYMROOT)/Release/mylib.a. Note that the library names are the same but they're in per-configuration directories, much like CodeWarior puts per-target intermediates into per-target directories.

Then drag the static library project and drop it into your app project. When you disclose it, it will show that it builds foo.a. Drag that into the Link Binaries with Libraries build phase of your target.

Then when you build the Debug configuration of your app, it will use the Debug build folder, and automatically pick up the Debug static library, and the same for the Release configuration.

If you really want the files in the same place and named differently, then you have to use separate targets for your Debug and Release versions of your app (and probably use just one configuration). Add the mylib_d.a static library to the Debug target and the mylib.a static library to the Release target, just like in CodeWarrior.

Chris