[cmake-developers] [CMake] Q: cmExportFileGenerator::GenerateImportedFileCheckLoop

[David Cole]

On Tue, Mar 13, 2012 at 1:10 PM, Alexander Neundorf
<a.neundorf-work at gmx.net> wrote:
> 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
> --
>
> 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

VTK is a monolithic package, too, and from VTK developers' perspective
not something to be split into independent sub-pieces. (That's about
to change with the upcoming "modularization" effort.)

However, the fact that you were able to split it into sub-packages for
a distribution is a fairly miraculous feat in itself...

If you're going to split it into such sub-pieces for a distribution,
without most VTK devs even knowing about this, then the onus should be
on you to make sure that the exports files created are suitable.

This new feature has simply pointed out that it's a mistake to try to
use these files as-is.