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