[CMake] Q: cmExportFileGenerator::GenerateImportedFileCheckLoop

[Mathieu Malaterre]

On Mon, Mar 12, 2012 at 9:33 PM, Alexander Neundorf
<a.neundorf-work at gmx.net> wrote:
> On Monday 12 March 2012, Mathieu Malaterre wrote:
>> Hi there,
>>
>>   CMake 2.8.7 recently added a new behavior when reading export files:
>>
>> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a2be068c
>>
>>   I perfectly understand the goal here, I think this is a great user
>> functionality. However this breaks the old behavior of cmake being
>> tolerant with missing files. This is particularly difficult to handle
>> for large package such as VTK. Currently in debian we split the VTK
>> package into sub-packages:
>>  * C++ dev,
>>  * Qt dev,
>>  * TCL,
>>  * Java and
>>  * Python bindings.
>>   Since there is a single export file, we are now forced to install
>> all those sub-packages while in the past we could bypass any cmake
>> internals checks and only install -say- C++-dev package.
>
> Here's my opinion on this: I understand the issue, but basically this is the
> purpose of the patch, to make an exports file fail if the files it describes
> are not actually present.
> I mean, if the debian packages did that, then the installed exports files were
> basically broken, since they created imported targets referencing non-existant
> files, so you would get link errors at build time.

My question was not about whether not this patch was a good thing, no
doubt about it.

My question was about making it a default and breaking an old behavior
with no possible evasion. CMake 2.8.7 is a minor release compare to
2.8.6.

> I think the proper way to make this work is to split the exports-file into
> multiple files.

This is another question: does cmake export file support
non-monolithic configuration. I believe it does not. When generating
the export file, cmake will loop over all exported targets and list
any missing one. It is not capable of recursing into sub-exported file
IMHO.

Regards,
-- 
Mathieu