[CMake] Package installation conundrum

David Cole david.cole at kitware.com
Wed May 9 16:05:26 EDT 2012


On Wed, May 9, 2012 at 4:01 PM, Alexander Neundorf
<a.neundorf-work at gmx.net> wrote:
> On Wednesday 09 May 2012, Michael Wild wrote:
>
>> On 09.05.2012, at 21:03, Alexander Neundorf <a.neundorf-work at gmx.net>
>> wrote:
>
> ...
>
>> > > # configure the headers into the build tree so the package can be used
>
>> > > # without installing it and not hard-coding the source/build directory
>
>> > > # information into FooConfig.cmake
>
>> > > configure_file(include/foo.h
>
>> > > ${PROJECT_BINARY_DIR}/include/foo.h COPYONLY)
>
>> >
>
>> > The input file should have a suffix which indicates it is a file which
>> > is
>
>> > intended to be configured, usually foo.h.in. Alex
>
>>
>
>> I don't agree, since it's COPYONLY. Besides, with a little more work in
>
>> FooConfig.cmake you can skip that step...
>
> Oh, sorry, I missed the COPYONLY.
>
> Alex
>
>
> --
>
> 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


FYI -- I know we discourage in-source builds heavily.... but -- we do
still support them, so:

And in such a case where the source and build trees are the same, it's
still important to use a .in extension (or something) on the input
file to make it different from the output file.

Use a .in extension on configure_file inputs unless you also have code
in place to prohibit in-source builds.


David


More information about the CMake mailing list