Permalink
Browse files

Set PUBLIC_HEADERS_FOLDER_PATH for static libraries by default

  • Loading branch information...
jspahrsummers committed Jan 6, 2013
1 parent ca05d1c commit eacb5ece2ccf08c748744dc943ac58b98f5aefa7
Showing with 5 additions and 0 deletions.
  1. +5 −0 Base/Targets/StaticLibrary.xcconfig
@@ -10,3 +10,8 @@ DEAD_CODE_STRIPPING = NO
// Whether function calls should be position-dependent (should always be
// disabled for library code)
GCC_DYNAMIC_NO_PIC = NO
+
+// Copy headers to "include/LibraryName" in the build folder by default. This
+// lets consumers use #import <LibraryName/LibraryName.h> syntax even for static
+// libraries
+PUBLIC_HEADERS_FOLDER_PATH = include/$PRODUCT_NAME

4 comments on commit eacb5ec

@diederich

This comment has been minimized.

Show comment Hide comment
@diederich

diederich Feb 5, 2013

Collaborator

Did you think about adjusting the PRIVATE_HEADERS_FOLDER_PATH as well?

In general, I have it set to PRIVATE_HEADERS_FOLDER_PATH = $(PUBLIC_HEADERS_FOLDER_PATH)/private.

With the current version of the templates it's /usr/local/include.

Collaborator

diederich replied Feb 5, 2013

Did you think about adjusting the PRIVATE_HEADERS_FOLDER_PATH as well?

In general, I have it set to PRIVATE_HEADERS_FOLDER_PATH = $(PUBLIC_HEADERS_FOLDER_PATH)/private.

With the current version of the templates it's /usr/local/include.

@jspahrsummers

This comment has been minimized.

Show comment Hide comment
@jspahrsummers

jspahrsummers Feb 5, 2013

Owner

Why does PRIVATE_HEADERS_FOLDER_PATH need to be set? Those are headers that shouldn't be accessible to any containing projects anyhow.

Owner

jspahrsummers replied Feb 5, 2013

Why does PRIVATE_HEADERS_FOLDER_PATH need to be set? Those are headers that shouldn't be accessible to any containing projects anyhow.

@diederich

This comment has been minimized.

Show comment Hide comment
@diederich

diederich Feb 6, 2013

Collaborator

Xcode provides 3 types of visibility for library headers: Public, Private and Project. I think what you describe are the Project type headers. Private is nice to have when testing APIs or if something is needed by a client but should not be, yeah, public :-) (data structures, inline methods, template specializations).

I didn't need it while porting projects over to this xcconfig set, which is also the reason why there is no pull request :-) I just stumbled over it when cleaning up the existing xcodeprojects.
Thanks for the comment.

Collaborator

diederich replied Feb 6, 2013

Xcode provides 3 types of visibility for library headers: Public, Private and Project. I think what you describe are the Project type headers. Private is nice to have when testing APIs or if something is needed by a client but should not be, yeah, public :-) (data structures, inline methods, template specializations).

I didn't need it while porting projects over to this xcconfig set, which is also the reason why there is no pull request :-) I just stumbled over it when cleaning up the existing xcodeprojects.
Thanks for the comment.

@jspahrsummers

This comment has been minimized.

Show comment Hide comment
@jspahrsummers

jspahrsummers Feb 6, 2013

Owner

Hmm, interesting. Thanks for explaining that. I haven't run into a use case like that for private headers, but I'll happily accept any future PRs about it.

Owner

jspahrsummers replied Feb 6, 2013

Hmm, interesting. Thanks for explaining that. I haven't run into a use case like that for private headers, but I'll happily accept any future PRs about it.

Please sign in to comment.