[CMake] Install header directory hierarchy

Daniel Pfeifer daniel at pfeifer-mail.de
Tue Oct 19 11:17:19 EDT 2010


> Please keep follow-up questions on list, so others may participate and
> benefit as well.

Oh, I did not realize that I sent my email off list. I just hit reply,
without double checking the recipient field.

> The Framework test demonstrates one (not pretty, not elegant, but
> possible) way to do what you want.
>
> Rather than using PUBLIC_HEADER to achieve the final location of the
> nested header file, use the source file property
> MACOSX_PACKAGE_LOCATION.
>
> add_library(foo SHARED
>   foo.cxx
>   ...
>   fooDeepPublic.h
> )
> set_property(SOURCE fooDeepPublic.h
>   PROPERTY MACOSX_PACKAGE_LOCATION Headers/Deep
>   )

Surely this is not the most elegant solution, but it is much more
acceptable than this one
<http://www.cmake.org/pipermail/cmake/2008-June/022378.html>

Thanks!

> The result of the foo.framework build on my Mac CMake build tree is as
> follows:
> 
> 
> davidcole at mymac : foo.framework 
> $ pwd
> <<...>>/CMake Mac-unix-Debug/Tests/Framework/foo.framework
> 
> 
> davidcole at mymac : foo.framework 
> $ find .
> .
> ./foo
> ./Headers
> ./PrivateHeaders
> ./Resources
> ./Versions
> ./Versions/Current
> ./Versions/ver4
> ./Versions/ver4/foo
> ./Versions/ver4/Headers
> ./Versions/ver4/Headers/Deep
> ./Versions/ver4/Headers/Deep/fooDeepPublic.h
> ./Versions/ver4/Headers/foo.h
> ./Versions/ver4/Headers/foo2.h
> ./Versions/ver4/Headers/fooPublic.h
> ./Versions/ver4/Headers/fooPublicExtensionlessHeader
> ./Versions/ver4/PrivateHeaders
> ./Versions/ver4/PrivateHeaders/fooBoth.h
> ./Versions/ver4/PrivateHeaders/fooPrivate.h
> ./Versions/ver4/PrivateHeaders/fooPrivateExtensionlessHeader
> ./Versions/ver4/Resources
> ./Versions/ver4/Resources/fooExtensionlessResource
> ./Versions/ver4/Resources/Info.plist
> ./Versions/ver4/Resources/test.lua
> 
> 
> 
> 
> HTH,
> David
> 
> 
> 
> 
> On Tue, Oct 19, 2010 at 8:26 AM, Daniel Pfeifer
> <daniel at pfeifer-mail.de> wrote:
>         Hi David,
>         
>         Am Freitag, den 15.10.2010, 10:42 -0400 schrieb David Cole:
>         > The best way to preserve structure is to layout the source
>         directory
>         > exactly as you want it, and then use a single
>         install(DIRECTORY
>         > command. If it's not in your source tree exactly as you want
>         it, you
>         > could add a custom build step to arrange such a directory in
>         your
>         > build tree, and then use install(DIRECTORY on that.
>         >
>         > An alternative would be to group headers that go together
>         using
>         > variables, one per destination directory, and then have one
>         > install(FILES rule for each separate destination directory.
>         
>         
>         Right, for the install(FILES) command there are a few
>         alternatives.
>         But what about the PUBLIC_HEADER property for mac frameworks?
>         
>         
>         > HTH,
>         > David
>         >
>         >
>         >
>         > On Fri, Oct 15, 2010 at 7:00 AM, Daniel Pfeifer
>         > <daniel at pfeifer-mail.de> wrote:
>         >         Hi,
>         >
>         >         This question has been asked quite a few times, but
>         never
>         >         satisfactorily
>         >         answerded before: How do I install a bunch of
>         headers
>         >         preserving
>         >         directory structure? The following snippet
>         >
>         >         > set(HEADERS header1.h dir/header2.h)
>         >         > install(FILES ${HEADERS} DESTINATION include)
>         >
>         >         puts both files inside the same directory. The
>         structure is
>         >         not
>         >         preserved. The following workaround does the trick:
>         >
>         >         > foreach(HEADER HEADERS)
>         >         >   string(REGEX MATCH "(.*)[/\\]" DIR ${HEADER})
>         >         >   install(FILES ${HEADER} DESTINATION
>         include/${DIR})
>         >         > endforeach(HEADER HEADERS)
>         >
>         >         However, I consider this as a workaround, not as a
>         solution!
>         >
>         >         It gets more complicated as soon as I want to build
>         frameworks
>         >         on mac,
>         >
>         >         > set_target_properties(my_lib PROPERTIES
>         PUBLIC_HEADER
>         >         ${HEADERS})
>         >
>         >         again puts both files inside the same directory,
>         ignoring
>         >         structure.
>         >         Here the workaround is even less a solution, if this
>         is really
>         >         the only
>         >         way:
>         >
>         <http://www.cmake.org/pipermail/cmake/2008-June/022378.html>
>         >
>         >         Hasn't this been considered before? The public wiki
>         shows two
>         >         use cases
>         >         of cmake frameworks, but neither of them puts
>         headers into a
>         >         directory
>         >         hierarchy.
>         <http://www.cmake.org/Wiki/CMake:MacOSX_Frameworks>
>         >
>         >         cheers, Daniel
>         >
>         >
>         >         _______________________________________________
>         >         Powered by www.kitware.com
>         >
>         >         Visit other Kitware open-source projects at
>         >         http://www.kitware.com/opensource/opensource.html
>         >
>         >         Please keep messages on-topic and check the CMake
>         FAQ at:
>         >         http://www.cmake.org/Wiki/CMake_FAQ
>         >
>         >         Follow this link to subscribe/unsubscribe:
>         >         http://www.cmake.org/mailman/listinfo/cmake
>         >
>         >
>         
>         
>         
> 
> 




More information about the CMake mailing list