MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013193CMakeCPackpublic2012-05-05 09:402013-01-09 10:57
ReporterShlomi Fish 
Assigned ToEric NOULARD 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Platformx86-64OSLinuxOS VersionMageia Linux 2
Product VersionCMake 2.8.7 
Target VersionCMake 2.8.9Fixed in VersionCMake 2.8.9 
Summary0013193: All the Files in the Source Tarballs (from "make package_source" on UNIX-like platforms) Have Close (and Arbitrary) Timestamps
DescriptionAll the Files in the Source Tarballs (from "make package_source" on UNIX-like platforms) Have Close (and Arbitrary) Timestamps. This is because the files are copied to their directories without preserving their original timestamps, in an arbitrary order (and then they are tarballed).

This interferes with my workflow because I keep some generated files in the source archive (without putting them in my CPACK_SOURCE_IGNORE_FILES ) so they will be available without being needed to be generated again (for example, some documentation files I have require AsciiDoc and the DocBook/XML toolchain to install, and I don't want to require the end-users to have it.). So "make" often tries to build them again and it may interfere with the workflow.
Steps To ReproduceOn Linux/UNIX: "mkdir build ; cd build ; cmake .. ; make package_source; tar -tvf *.tar.gz | less"
Additional Information
TagsNo tags attached.
Relationships
related to 0012865closed Kitware Robot CPack generated archives don't have correct permissions when cross compiling on windows 
Attached Filespatch 0001-CPack-preserve-timestamp-for-CPACK_INSTALLED_DIRECTO.patch (1,267) 2012-05-09 12:05
https://public.kitware.com/Bug/file/4321/0001-CPack-preserve-timestamp-for-CPACK_INSTALLED_DIRECTO.patch
Issue History
Date ModifiedUsernameFieldChange
2012-05-05 09:40Shlomi FishNew Issue
2012-05-07 07:11Eric NOULARDNote Added: 0029409
2012-05-08 03:38Shlomi FishNote Added: 0029417
2012-05-09 07:16Shlomi FishNote Added: 0029429
2012-05-09 12:00Eric NOULARDNote Added: 0029432
2012-05-09 12:05Eric NOULARDAssigned To => Eric NOULARD
2012-05-09 12:05Eric NOULARDStatusnew => assigned
2012-05-09 12:05Eric NOULARDFile Added: 0001-CPack-preserve-timestamp-for-CPACK_INSTALLED_DIRECTO.patch
2012-05-09 12:06Eric NOULARDNote Added: 0029433
2012-05-09 14:51Shlomi FishNote Added: 0029437
2012-05-09 16:57Eric NOULARDNote Added: 0029461
2012-05-09 16:57Eric NOULARDStatusassigned => resolved
2012-05-09 16:57Eric NOULARDResolutionopen => fixed
2012-05-09 16:58Eric NOULARDStatusresolved => feedback
2012-05-09 16:58Eric NOULARDResolutionfixed => reopened
2012-05-09 16:58Eric NOULARDStatusfeedback => resolved
2012-05-09 16:58Eric NOULARDResolutionreopened => fixed
2012-05-09 16:58Eric NOULARDTarget Version => CMake 2.8.9
2012-08-09 19:34David ColeFixed in Version => CMake 2.8.9
2012-08-12 03:12Eric NOULARDRelationship addedrelated to 0012865
2013-01-09 10:57Robert MaynardNote Added: 0032046
2013-01-09 10:57Robert MaynardStatusresolved => closed

Notes
(0029409)
Eric NOULARD   
2012-05-07 07:11   
It would be nice to fulfill your need but currently source packaging is done
by CPack using a copy to a temp place (as you noticed).

The "real" trouble is that currently CPack know nothing about "Source" package,
for CPack sources packages are "normal" packages which are "installed" using a directory name.

If you look at CPackSourceConfig.cmake generated by CPack.cmake you'll see that this file sets CPACK_INSTALLED_DIRECTORIES (and not CPACK_INSTALL_CMAKE_PROJECTS as CPackConfig.cmake does).

This makes CPack copy the content of the specified directories (in this case a single one, the source directory) to <buildtree>/_CPack_Packages/xxxx-Source/<GENNAME>/TOPDIR/.

The copy filters the files matching "CPACK_SOURCE_IGNORE_FILES".

Then this directory is "packaged" using the choosen CPack generator.
Changing this workflow for "source" package may not be that simple
in the general case.

I don't know if it's even worth the effort.

If you want to distribute source which does not need some tool to be there
to be compiled then I suggest you add some CMake option

REGENERATE_WHATEVER_FILE

whose default is "OFF".

your custom target/command may be guarded by an

IF(REGENERATE_WHATEVER_FILE)
...
ENDIF()


developer have then to know that they must toggle REGENERATE_WHATEVER_FILE to ON whereas "standard" user won't be bothered by the regeneration of those files.

I know it's a workaround, but what do you think?
(0029417)
Shlomi Fish   
2012-05-08 03:38   
@Eric: I have read your message (though I have yet to read it thoroughly) and I will make a full reply to it as soon as I get to it. Please stay tuned.
(0029429)
Shlomi Fish   
2012-05-09 07:16   
@Eric: I now understand the issue with the copying, but I don't see why one cannot set the timestamps of the copied files to those of their source files (perhaps in all cases), using the UNIX utime() system call (or its Win32 equivalent). This is done elsewhere in the CPack code, but is not used for the installing to the source directories.

As a proof of concept, I have written a Perl program, that takes the archives produced by CMake, unpacks them, sets the timestamps of the files to the ones of the files in the source directory and repackages the tarballs. It can be found here:

http://code.google.com/p/fc-solve/source/browse/fc-solve/source/scripts/normalize-cmake-source-tarballs-time-stamps.pl [^]

I've also written a wrapper around it as a "make dist" target at the bottom of:

http://code.google.com/p/fc-solve/source/browse/fc-solve/source/CMakeLists.txt [^]

This fixed the problems I had (after I fixed another bug I had in the CMakeLists.txt file).

Regards,

-- Shlomi Fish
(0029432)
Eric NOULARD   
2012-05-09 12:00   
Hi Shlomi,

Yes you are almost right.
You are right we could copy file time, a function is already there for
that in the CMake source: cmSystemTools::CopyFileTime.

But I doubt that any CPack code do take care of that.
The "FILE(INSTALL" command used in cmake_install.cmake script generated
by CMake.

What happen is that files installed with "cmake_install.cmake" scripts
do get appropriate timestamp but CPACK_INSTALLED_DIRECTORIES don't.

The function to be modified for CPack is this one:
cmCPackGenerator::InstallProjectViaInstalledDirectories
for which we may add the extra cmSystemTools::CopyFileTime where it is missing.

I'll try a patch, stay tuned.
(0029433)
Eric NOULARD   
2012-05-09 12:06   
Patch against CMake master is attached.
Would you be able to try whether if it works for you?
(0029437)
Shlomi Fish   
2012-05-09 14:51   
Hi Eric,

your patch works fine for me and my use case. "make test" passes with blazing colours.

Regards,

-- Shlomi Fish
(0029461)
Eric NOULARD   
2012-05-09 16:57   
Merge topic 'CPack-preserveTimestampInSourcePackage' into next

3d10f65 CPack - preserve timestamp for CPACK_INSTALLED_DIRECTORIES. fixes: 0013193
(0032046)
Robert Maynard   
2013-01-09 10:57   
Closing resolved issues that have not been updated in more than 4 months.