[CMake] Setting the installation order of a script

[Michael Hertling]

On 07/15/2011 05:41 PM, David Cole wrote:
> On Fri, Jul 15, 2011 at 10:55 AM, Michael Hertling <mhertling at online.de> wrote:
>> On 07/14/2011 02:34 PM, David Cole wrote:
>>> The only way to guarantee that your install SCRIPT and CODE segments
>>> run last is to put them in their own subdirectory, and add it last.
>>>
>>> i.e. :
>>> dir3/CMakeLists.txt:
>>> INSTALL (SCRIPT setpermissions.cmake)
>>>
>>> CMakeLists.txt:
>>> ADD_SUBDIRECTORY(dir1)
>>> ADD_SUBDIRECTORY(dir2)
>>> # last, so it's install rules run after all other install rules
>>> ADD_SUBDIRECTORY(dir3)
>>
>> If I understand correctly, this is exactly what's *not* guaranteed:
>>
>> "Rules specified by calls to this command within a source directory are
>> executed in order during installation. The order across directories is
>> not defined." (documentation of INSTALL() command)
>>
>> Perhaps, the CMake manual could be clarified in this regard since the
>> INSTALL() commands' order of execution is sometimes quite important.
>>
>> Regards,
>>
>> Michael
>>
>>> On Thu, Jul 14, 2011 at 4:51 AM, Mathias Tausig
>>> <mathias.tausig at a-cert.at> wrote:
>>>> Hy!
>>>>
>>>> My CMakeLists.txt in the top directory looks like this:
>>>>
>>>> ADD_SUBDIRECTORY(dir1)
>>>> ADD_SUBDIRECTORY(dir2)
>>>> INSTALL (SCRIPT setpermissions.cmake)
>>>>
>>>> setpermissions.cmake changes some file-owner permissions of the stuff
>>>> that has been installed from dir1 and dir2. The problem is: if I execute
>>>> "make install", setpermissions is run previous to the installation from
>>>> the subdirectories.
>>>> Is there some way to make the script from the last line wait, until
>>>> everything else has been installed?
>>>> I am using cmake-2.8.3 under linux.
>>>>
>>>> cheer
>>>> Mathias
>> _______________________________________________
>> 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
>>
> 
> Given that add_subdirectory calls are processed in order, and that
> install rules within a directory are processed in order within that
> directory, it follows that:
> 
> Given:
> add_subdirectory(dir1)
> add_subdirectory(dir2)
> add_subdirectory(dir3)
> 
> Yields install rules running in the predictable order that you'd expect.

The processing order of ADD_SUBDIRECTORY() commands is guaranteed at
configuration time, and the processing order of install rules due to
INSTALL() commands within the same CMakeLists.txt file is guaranteed
at installation time. IMO, these two assertions aren't sufficient to
derive your above-noted statement since it is absolutely common that
build/installation time actions take place in a different order than
the corresponding configuration time actions. Anyway, it's great that
it works nonetheless; indeed, I could have made good use of this in
the past but I never did as I supposed it just works by accident.

> However, what most don't expect, and what is actually true, is that
> interleaving install calls and add_subdirectory calls do not yield the
> same interleaving in the generated install files. Hence, you cannot
> simply do an install(SCRIPT at the bottom of your main CMakeLists file
> and have it run after all the install rules from all the previous
> sub-directories. That's unexpected to most. Which leads to the "not
> defined" documentation you've pointed out. By leaving it undefined,
> we're reserving the right to *try* to possibly re-factor/re-arrange it
> in the future, perhaps changing it and defining it later.
> 
> Practically speaking, I don't give that a very good chance, because
> many projects out there are already relying on some portions of the
> existing actual, in practice behavior despite the fact that it's
> undefined.
> 
> What I'm saying here is: I've done this myself in some projects, and
> know that it works, and don't expect it to change in the near future.
> Despite the "not defined" blurb in the docs.

As for me, it's completely OK if the processing order of install rules
is not guranteed across descendant directories, but if it is guranteed
across sibling directories, this should be stated in the documentation
because it's currently not evident, if I'm not mistaken.

Regards,

Michael