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