file(COPY) is copying even if file hasn't changed

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

file(COPY) is copying even if file hasn't changed

Robert Dailey-2
According to the documentation for file(COPY) [1]: "Copying preserves
input file timestamps, and optimizes out a file if it exists at the
destination with the same timestamp"

However this is not the case. My host OS is Windows 10 and I'm using
CMake 3.9.0-rc5. Each time my CMakeLists.txt is run, the file(COPY) is
copying over the file even if it didn't change. The "date modified"
timestamp for the destination file is updated. I do not want the copy
to occur if the source file has not changed (this appears to be the
intended behavior based on the documentation).

Am I understanding this correctly or is this a bug?

[1]: https://cmake.org/cmake/help/latest/command/file.html
--

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
Reply | Threaded
Open this post in threaded view
|

Re: file(COPY) is copying even if file hasn't changed

Robert Dailey-2
Oh also file(INSTALL) does the same thing; the "Installing:" message
gets printed each time for the same file, and never says that it is
"up to date".

On Wed, Jul 19, 2017 at 4:04 PM, Robert Dailey <[hidden email]> wrote:

> According to the documentation for file(COPY) [1]: "Copying preserves
> input file timestamps, and optimizes out a file if it exists at the
> destination with the same timestamp"
>
> However this is not the case. My host OS is Windows 10 and I'm using
> CMake 3.9.0-rc5. Each time my CMakeLists.txt is run, the file(COPY) is
> copying over the file even if it didn't change. The "date modified"
> timestamp for the destination file is updated. I do not want the copy
> to occur if the source file has not changed (this appears to be the
> intended behavior based on the documentation).
>
> Am I understanding this correctly or is this a bug?
>
> [1]: https://cmake.org/cmake/help/latest/command/file.html
--

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
Reply | Threaded
Open this post in threaded view
|

Re: file(COPY) is copying even if file hasn't changed

Robert Dailey-2
FYI I decided to file an issue for this here:
https://gitlab.kitware.com/cmake/cmake/issues/17087

On Wed, Jul 19, 2017 at 4:05 PM, Robert Dailey <[hidden email]> wrote:

> Oh also file(INSTALL) does the same thing; the "Installing:" message
> gets printed each time for the same file, and never says that it is
> "up to date".
>
> On Wed, Jul 19, 2017 at 4:04 PM, Robert Dailey <[hidden email]> wrote:
>> According to the documentation for file(COPY) [1]: "Copying preserves
>> input file timestamps, and optimizes out a file if it exists at the
>> destination with the same timestamp"
>>
>> However this is not the case. My host OS is Windows 10 and I'm using
>> CMake 3.9.0-rc5. Each time my CMakeLists.txt is run, the file(COPY) is
>> copying over the file even if it didn't change. The "date modified"
>> timestamp for the destination file is updated. I do not want the copy
>> to occur if the source file has not changed (this appears to be the
>> intended behavior based on the documentation).
>>
>> Am I understanding this correctly or is this a bug?
>>
>> [1]: https://cmake.org/cmake/help/latest/command/file.html
--

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
Reply | Threaded
Open this post in threaded view
|

Re: file(COPY) is copying even if file hasn't changed

Nicholas Devenish
For what it's worth, I'm not seeing this on Sierra 10.12.5, CMake
3.9.0<release> on a simple test case of:

    cmake_minimum_required(VERSION 3.5 FATAL_ERROR)
    file(COPY afile DESTINATION .)

I ran through Instruments to check the otherwise silent copy, it
copies the first time but thereafter only stat calls are ever made,
the file timestamp stays matching the source, and even the INSTALL
option also gives the "Up-to-date" message. It looks as though a chmod
might be run, but that doesn't seem to affect the output stamp.

So it must be something more complicated. Are you able to reduce the
behaviour to a simple test-case?

Completely wild guess: Are you running on something different from
HFS, like APFS? If my reading of the chmod isn't wrong, I suppose *in
theory* a different filesystem could treat a chmod attempt as a
modification....

Nick

On Thu, Jul 20, 2017 at 5:00 PM, Robert Dailey <[hidden email]> wrote:

> FYI I decided to file an issue for this here:
> https://gitlab.kitware.com/cmake/cmake/issues/17087
>
> On Wed, Jul 19, 2017 at 4:05 PM, Robert Dailey <[hidden email]> wrote:
>> Oh also file(INSTALL) does the same thing; the "Installing:" message
>> gets printed each time for the same file, and never says that it is
>> "up to date".
>>
>> On Wed, Jul 19, 2017 at 4:04 PM, Robert Dailey <[hidden email]> wrote:
>>> According to the documentation for file(COPY) [1]: "Copying preserves
>>> input file timestamps, and optimizes out a file if it exists at the
>>> destination with the same timestamp"
>>>
>>> However this is not the case. My host OS is Windows 10 and I'm using
>>> CMake 3.9.0-rc5. Each time my CMakeLists.txt is run, the file(COPY) is
>>> copying over the file even if it didn't change. The "date modified"
>>> timestamp for the destination file is updated. I do not want the copy
>>> to occur if the source file has not changed (this appears to be the
>>> intended behavior based on the documentation).
>>>
>>> Am I understanding this correctly or is this a bug?
>>>
>>> [1]: https://cmake.org/cmake/help/latest/command/file.html
> --
>
> 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
--

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
Reply | Threaded
Open this post in threaded view
|

INTERPROCEDURAL_OPTIMIZATION still not using CMAKE_<LANG>_COMPILER_AR

Lectem

Hello guys,

 

So I downloaded the 3.9 release and thought my LTO nightmares were over but… cmake still isn’t using

CMAKE_<LANG>_COMPILER_AR when linking on MSYS.

 

I’m using the « MSYS Makefiles » generator, and when building an executable it still uses the plain ar instead of gcc-ar…

 

CMAKE_CXX_COMPILER_AR is correctly set to C:/msys64/mingw64/bin/gcc-ar.exe but won’t use it…

I also tried to set CMAKE_AR to C:/msys64/mingw64/bin/gcc-ar.exe from cmake-gui but it’s not taken into account

Here’s the output :

 

[100%] Linking CXX executable BoilerPlate.exe

"/C/Program Files/CMake/bin/cmake.exe" -E remove -f CMakeFiles/BoilerPlate.dir/objects.a

/C/msys64/mingw64/bin/ar.exe cr CMakeFiles/BoilerPlate.dir/objects.a @CMakeFiles/BoilerPlate.dir/objects1.rsp

C:\msys64\mingw64\bin\ar.exe: CMakeFiles/BoilerPlate.dir/source/main.cpp.obj: plugin needed to handle lto object

/C/msys64/mingw64/bin/g++.exe -flto -fno-fat-lto-objects   -Wl,--whole-archive CMakeFiles/BoilerPlate.dir/objects.a -Wl,--no-whole-archive  -o BoilerPlate.exe -Wl,--out-implib,libBoilerPlate.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/BoilerPlate.dir/linklibs.rsp

 

I’m not sure if it is a Windows/MSYS related problem (I think it is), but I really don’t understand why CMAKE wants to use C:/msys64/mingw64/bin/ar.exe so much and not the one in CMAKE_AR / CMAKE_CXX_COMPILER_AR…

 

If you guys have any idea.

 

Thanks,

Lectem


--

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
Reply | Threaded
Open this post in threaded view
|

Re: INTERPROCEDURAL_OPTIMIZATION still not using CMAKE_<LANG>_COMPILER_AR

Brad King
On 07/22/2017 07:33 AM, [hidden email] wrote:
> So I downloaded the 3.9 release and thought my LTO nightmares we over but
> cmake still isn't using CMAKE_<LANG>_COMPILER_AR when linking on MSYS.

The problem is that this code:

  https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Modules/Platform/Windows-GNU.cmake#L117-127

inserts use of the archiver into the main linking process as a way
to work around Windows command-line length limits.  Since it is
using the archiver as part of linking instead of just for creating
a static library, our logic to switch to CMAKE_<LANG>_COMPILER_AR
for LTO is not triggering.

-Brad
--

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
Reply | Threaded
Open this post in threaded view
|

Re: INTERPROCEDURAL_OPTIMIZATION still not using CMAKE_<LANG>_COMPILER_AR

Hendrik Sattler


Am 1. August 2017 22:52:09 MESZ schrieb Brad King <[hidden email]>:

>On 07/22/2017 07:33 AM, [hidden email] wrote:
>> So I downloaded the 3.9 release and thought my LTO nightmares we over
>but
>> cmake still isn't using CMAKE_<LANG>_COMPILER_AR when linking on
>MSYS.
>
>The problem is that this code:
>
>https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Modules/Platform/Windows-GNU.cmake#L117-127
>
>inserts use of the archiver into the main linking process as a way
>to work around Windows command-line length limits.  Since it is
>using the archiver as part of linking instead of just for creating
>a static library, our logic to switch to CMAKE_<LANG>_COMPILER_AR
>for LTO is not triggering.

And the code to detect that gcc uses GNU ld is broken as it does not check if gcc was actually built using the right configure flags!
If it isn't configured for GNU ld, it does not forward the response file to the collect2 command and the command line length thing breaks it. This is independent of the actual ld binary.

HS


--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
--

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
Reply | Threaded
Open this post in threaded view
|

Re: INTERPROCEDURAL_OPTIMIZATION still not using CMAKE_<LANG>_COMPILER_AR

Lectem
In reply to this post by Brad King
Should I file a bug report for this? 

Le mar. 1 août 2017 à 22:52, Brad King <[hidden email]> a écrit :
On 07/22/2017 07:33 AM, [hidden email] wrote:
> So I downloaded the 3.9 release and thought my LTO nightmares we over but
> cmake still isn't using CMAKE_<LANG>_COMPILER_AR when linking on MSYS.

The problem is that this code:

  https://gitlab.kitware.com/cmake/cmake/blob/v3.9.0/Modules/Platform/Windows-GNU.cmake#L117-127

inserts use of the archiver into the main linking process as a way
to work around Windows command-line length limits.  Since it is
using the archiver as part of linking instead of just for creating
a static library, our logic to switch to CMAKE_<LANG>_COMPILER_AR
for LTO is not triggering.

-Brad

--

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
Reply | Threaded
Open this post in threaded view
|

Re: INTERPROCEDURAL_OPTIMIZATION still not using CMAKE_<LANG>_COMPILER_AR

Brad King
On 08/12/2017 03:28 AM, Clément Gregoire wrote:
> Should I file a bug report for this?

Yes, please.

Thanks,
-Brad
--

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