Re: [CMake] cmake install behaviour with git
> What was unclear to me is that it now sounds like you are installing two > distinct files from your repository to the same destination file rather > than re-installing a modified version of the same file. Yes, your are right i am doing exactly this > I think that is conceptually an error prone thing to do irregardless of > the SCM in use. yes you are right, but it worked until the git change :-) i will fix it in your CMakeLists.txt -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cmake install behaviour with git
On 10/01/2015 10:12 AM, Jörg Kreuzberger wrote: -Ursprüngliche Nachricht- Von:Nils Gladitz Gesendet: Do 01.10.2015 09:40 Betreff:Re: [CMake] cmake install behaviour with git An: Jörg Kreuzberger ; cmake@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. Subversion does not restore "original" modification times either (unless you use the non-default 'use-commit-times' option which likely breaks timestamp logic in the build). When you do a fresh checkout with subversion all files will have modification times close to each other as well. I guess the only difference with git is that git might be a bit faster when creating files to a degree where creation time differences might fall below the modification time precision(?) What was unclear to me is that it now sounds like you are installing two distinct files from your repository to the same destination file rather than re-installing a modified version of the same file. I think that is conceptually an error prone thing to do irregardless of the SCM in use. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cmake install behaviour with git
-Ursprüngliche Nachricht- Von:Nils Gladitz Gesendet: Do 01.10.2015 09:40 Betreff:Re: [CMake] cmake install behaviour with git An: Jörg Kreuzberger ; cmake@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! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cmake install behaviour with git
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? Could you provide a minimal, self-contained test case that reproduces this issue? I do agree with you, except for this scenario of non-builded files. So the question is ok, why not consider the file size in up-to-date check. Should be not to expensive to get this information together with the file time from the os. I don't think that makes much sense. A modified file is much more likely to retain its size than its modification time. 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. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cmake install behaviour with git
> > > > Now install behaves differnt, cause cmake checks only file time difference. > Files previously overwritten are now > > considered Up-to-date > > Why would you want to overwrite files that have not changed? 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. The same "application install" is used in "product install" there we bundle several applications to an "product" and then apply product specific configuration, modifying some xml files (same name, different size, normaly different timestamp :-) ) The idea behind this install overwrite is that we could provide an install for an application with "default" configuration, so that any developer could use the application without further need to add additonal files (all files to run the application like config files, shared libraries and so on). > We?re using CMake with git without any trouble - no solution to be found. The > install target works flawlessly and as expected. I do agree with you, except for this scenario of non-builded files. So the question is ok, why not consider the file size in up-to-date check. Should be not to expensive to get this information together with the file time from the os. > I think you?ll need to provide some more details about what you?re doing. Are > you by any chance doing in-source builds? Why are you so focussed on 'git > clone?? That is the kind of thing you would do once, and then almost never > again, so I don?t see how that can be related to running an install target. We do not make an in-source-builds. i am focused on git clone cause we do it on our SOFTWARE RELEASE systems. These are virtual machines, upstarting for any release build, cloning (with depth=1) the software and start builds, install, and package creation (rpm and msi). For those builds the "former" behaviour is broken. I do also not want to start a discussion about this git clone behaviour, i accepted this as is. I think the solutions provided in groups, aplying the timestamps after checkout from any meta data is also no good idea. The concept of the modified timestamps is also still good for the builded install files. Thanks for your patience, if you read this mail to the end :-) Joerg -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cmake install behaviour with git
Hej, > > Now install behaves differnt, cause cmake checks only file time difference. > Files previously overwritten are now > considered Up-to-date Why would you want to overwrite files that have not changed? > Has anyone found a solution for this after a git migration? We’re using CMake with git without any trouble - no solution to be found. The install target works flawlessly and as expected. I think you’ll need to provide some more details about what you’re doing. Are you by any chance doing in-source builds? Why are you so focussed on 'git clone’? That is the kind of thing you would do once, and then almost never again, so I don’t see how that can be related to running an install target. Sincerely, Jakob -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] cmake install behaviour with git
Hi! the cmake install behaviour of files was ok for me, as long as we used svn. Now we changed to git and i have a problem now with the install behaviour. On git the timestamps of all files get the time of the clone. So files not build (e.g. configuration files, xml files etc) from the repository have the same timestamp. Now install behaves differnt, cause cmake checks only file time difference. Files previously overwritten are now considered Up-to-date I am forcing now overwrite with CMAKE_ALWAYS_INSTALL, but this takes then a long time, cause now all binary files (with differnt timestamps) get installed (e.g. huge qt dlls, executables etc :-) ) Has anyone found a solution for this after a git migration? Adapting the file timestamps after clone seems not the thing i want to do :-) Or should i post a feature-request to check also the file size for Up-to-date checking? Thanks for any hints, Joerg -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
