[CMake] cmake install behaviour with git

Jörg Kreuzberger j.kreuzberger at procitec.de
Thu Oct 1 04:12:35 EDT 2015


-----Ursprüngliche Nachricht-----
Von:	Nils Gladitz <nilsgladitz at gmail.com>
Gesendet:	Do 01.10.2015 09:40
Betreff:	Re: [CMake] cmake install behaviour with git
An:	Jörg Kreuzberger <j.kreuzberger at procitec.de>; cmake at cmake.org; 
> On 10/01/2015 08:35 AM, Jörg Kreuzberger wrote:
> > This comes from installs, there we install some configuration files with the 
> builded targets.
> > e.g. you install a builded executable, together with an config xml file from 
> SCM.
> > If you make a product install, you want to "overwrite" the original config 
> xml with an "product" xml config
> > file, also from the SCM.
> >
> > So there are two install steps, the second "configure/modify" some files of 
> the first. This worked cause the file
> > timestamps differed. Now not, cause the second install gets "Up-to-date" 
> message and has to use CMAKE_ALWAYS_INSTALL.
> 
> I don't comprehend this at all.
> Why would the two instances of the config file with distinct content 
> have the same modification time in this scenario?

cause they come from git clone and git sets the timestamp of the files to the time of the clone,
not of the "original" modification time. So after a clone all files(!) have the same timestamp.

> Could you provide a minimal, self-contained test case that reproduces 
> this issue?
should be now problem, i send it later to you.

> I don't think that makes much sense.
> 
> A modified file is much more likely to retain its size than its 
> modification time.
i sense of "builded files" yes, in sense of files only coming from SCM not

> So if modification times really stay the same for some reason the file 
> size on its own would be a very error prone change indicator.
But better than noting. best would be a hash to detect modified content, but this will take some time to prove...

Ok, as i now understood nobody has a similar scenario and i will try to get it workaround by myself

Thanks all for support!



More information about the CMake mailing list