[CMake] Q: cmExportFileGenerator::GenerateImportedFileCheckLoop

[Alexander Neundorf]

On Tuesday 13 March 2012, Mathieu Malaterre wrote:
> 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 understand the problem, but I really wouldn't say it "broke old behaviour", 
but that it made an existing hidden breakage visible. I.e. I consider it 
broken to install an exports-file which references files on disk which do not 
exist, and cmake does not detect this. So I would see it as a bug in previous 
cmake versions that it did not detect this.
I mean, if somebody was using this file he got link errors when building, 
which is IMO clearly a symptom of a bug on the cmake side, instead of cmake 
complaining at configure time that the package is unusable.

One option for cmake 2.8.8 would be, instead of erroring out to consider the 
package not found.
Would this change something for you ?

> > 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.

Yes, this is missing.

Alex