Featured post
Duplicate interface definition when mixing Objective-C files in projects in XCode -
i have situation have 1 xcode project, , have project shares of code it, small differences. in project, of files references files original project, , anywhere need make differences, copy file , change copy. useful because files shared, changes made in 1 project automatically reflected in other. has worked fine part.
now running problem need make change in header file included among lot of files. call file "shared.h". same thing did before, delete reference , copy file on , change it.
but problem when compile, hundreds of "duplicate interface declaration" errors files include header. understand why, can't think of way fix it.
the reason suppose have file includes headers both original project , new project. in files references original project, when #import "shared.h"
, import file directory of original project; , in files copied new project, when #import "shared.h"
, import file directory of new project. classes defined in header imported twice 2 different files, hence duplicate interface definition. objective-c's #import
include once per file, since these 2 different files, still include both of them.
i thought header listed in project take precedence on else (at least want that), appears putting headers project don't affect building of code @ all. lost.
the solution can think of @ point duplicate code in original project , move over, separate projects. terrible.
hmm, actual think more of problem project management. think linking in code project sounds fragile. i.e. if project original project , project b links in of it's code, changes project may break project b without project b having ability restrict or control influence of changes.
i'd consider compiling first project static library or framework , giving version number. second project can import library. overrides should not handled manipulating class path. i've seen done in java , it's absolute last resort work around bad code. instead should making use of objective c's abilities - inheritance, categories, etc add or extend functionality.
if have versioned first project (i.e. /v0.0.1/headers) project b can keep using v0.0.1 of until read upgrade v0.0.2. can re-import a's static library, update build path or whatever point b @ new version want code against.
in summary, not recommend technique of project management @ , suggest rethink it.
- Get link
- X
- Other Apps
Comments
Post a Comment