Bug 24574

Summary: 'make install' does not preserve timestamp causing dependents to rebuild
Product: xorg Reporter: Gaetan Nadon <memsize>
Component: Build/ModularAssignee: Gaetan Nadon <memsize>
Status: RESOLVED WONTFIX QA Contact: Xorg Project Team <xorg-team>
Severity: minor    
Priority: low CC: alan.coopersmith, jeremyhu, peter.hutterer
Version: gitKeywords: janitor
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard: 2011BRB_Reviewed
i915 platform: i915 features:

Description Gaetan Nadon 2009-10-16 11:05:13 UTC
After doing a full build, running build.sh again rebuilds many modules. When installing headers and libraries the second time, the timestamp are not preserved. 

This is not unique to xorg, jhbuild has written a C install program which preserves timestamp (util/install-check). However it only deals with header files. Another solution is to use the automake install-sh script which is portable. 

There is a comment to the effect that the script is slower. I have used it in the proto directories for all extensions. For a few files to copy, there is no performance issue. GNU takes care of maintenance and portability.

This is implemented with the following line in configure.ac:

AC_SUBST([INSTALL], ['$(install_sh) -c -C'])

This must have been tried in the past (or at least in other projects). I'd like to collect this information in this bug report.
Comment 1 Peter Hutterer 2009-10-22 21:45:47 UTC
(In reply to comment #0)
> AC_SUBST([INSTALL], ['$(install_sh) -c -C'])

just a comment here - my manpage says that -c is ignored.
Comment 2 Gaetan Nadon 2009-10-23 08:04:16 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > AC_SUBST([INSTALL], ['$(install_sh) -c -C'])
> 
> just a comment here - my manpage says that -c is ignored.
> 

Correct. The GNU install executable program ignores the -c option. Automake always invokes it with -c option. The install-sh script also ignores it.

I used it for two reasons. To follow the tradition and to make it clear that -C is important and is not a typo of -c. 

I just realized I made a typo in configure.ac, it's "-sh" and not "_sh", but configure changed it. 

Thanks
Comment 3 Julien Cristau 2009-10-23 08:08:14 UTC
On Fri, 2009-10-16 at 11:05 -0700, bugzilla-daemon@freedesktop.org
wrote:
> After doing a full build, running build.sh again rebuilds many modules. When
> installing headers and libraries the second time, the timestamp are not
> preserved. 
> 
> This is not unique to xorg, jhbuild has written a C install program which
> preserves timestamp (util/install-check). However it only deals with header
> files. Another solution is to use the automake install-sh script which is
> portable. 

Then why does X need to work around this, as opposed to filing a
wishlist request to gnu install and leaving it at that?  Seems like a
lot of work for this...
Comment 4 Gaetan Nadon 2009-10-26 07:07:36 UTC
(In reply to comment #3)
> On Fri, 2009-10-16 at 11:05 -0700, bugzilla-daemon@freedesktop.org
> wrote:
> > After doing a full build, running build.sh again rebuilds many modules. When
> > installing headers and libraries the second time, the timestamp are not
> > preserved. 
> > 
> > This is not unique to xorg, jhbuild has written a C install program which
> > preserves timestamp (util/install-check). However it only deals with header
> > files. Another solution is to use the automake install-sh script which is
> > portable. 
> 
> Then why does X need to work around this, as opposed to filing a
> wishlist request to gnu install and leaving it at that?  Seems like a
> lot of work for this...
> 

It looks like this was settled in 2006:

http://lists.gnu.org/archive/html/automake/2006-12/msg00053.html

I forgot to mention that the "install" executable program has an option to preserve timestamp, bit it is commented as not being portable. It looks like the prevaling scenario is performance during installation rather than performance during build. In any case, we would still need to add a line in configure.ac. We only need to to do that for modules upon which other depends.


Comment 5 Jeremy Huddleston Sequoia 2011-10-07 16:09:03 UTC
So then can this be closed?  If not, what needs to be done?
Comment 6 Gaetan Nadon 2011-10-07 17:03:28 UTC
On hold for the foreseeable future.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.