Re: build.pl debug=1 for sw and svx
tora - Takamichi Akiyama <[email protected]> Thu, 07 Apr 2011 04:18:35 +0900
| Newsgroups | gmane.comp.openoffice.devel.general |
|---|---|
| Message-ID | <[email protected]> |
Hi Michael,
On 2011/04/07 2:47, Michael Stahl wrote:
>> make -r deliverlog running on OpenSolaris x86 prints same type of warning messages and then eventually create the log file.
>>
>> $ make -r deliverlog
>> ...
>> make: *** Warning: .LOW_RESOLUTION_TIME file `/xxxxx/solver/300/unxsoli4/inc/svx/sxsoitm.hxx' has a high resolution time stamp
>> ...(repeated 2 by 500 times for each file)...
>
> yes, this warning is a well-known problem.
>
>> On OpenSolaris x86, even after executing "make -sr&& make -r deliverlog," the "delivered" file under $OUTDIR is slightly older (in nanoseconds) than its original one. Consequently, copy action might occur again and again. Should I use /usr/gnu/bin/cp instead of /bin/cp, or else???
>
> btw, in DEV300m106 configure will now find /usr/gnu/bin/cp on Solaris, and
> use it :)
Good!
>> $ stat $OUTDIR/inc/svx/sxsoitm.hxx
>> ...
>> Modify: 2011-02-22 20:59:42.717474000 +0900
>> ...
>>
>> $ stat svx/inc/svx/sxsoitm.hxx
>> ...
>> Modify: 2011-02-22 20:59:42.717474450 +0900
>> ...
>
> that is exactly the problem that is solved by using the
> .LOW_RESOLUTION_TIME directive in the rules in Deliver.mk.
>
> ZFS has nano-second precision timestamps.
> as mentioned above, when copying files to the solver, gbuild preserves the
> timestamp of the source files, to prevent rebuilds in dependent modules.
> this is done using --preserve=timestamp option of GNU cp if it is
> available, and touch -r otherwise (such as in your case probably).
>
> unfortunately older versions of GNU cp, as well as Solaris 10 touch, only
> support micro-second precision timestamps.
> the result is that on every make invocation the files will be copied
> again, which is bad.
>
> to work around this, GNU make provides the .LOW_RESOLUTION_TIME option,
> which does not check the sub-second part of the timestamp.
>
> however, because the timestamps do have a sub-second part that is not
> zero, GNU make produces this annoying warning, and unfortunately there
> seems to be no way to turn it off.
>
> i haven't checked yet, but if the GNU cp in OpenSolaris can actually copy
> nano-second timestamps properly, then you can set the gb_HIRESTIME
> variable, so the .LOW_RESOLUTION_TIME is not used and the warnings go away.
I've just tried it and learned that unfortunately, version 6.7 of "/usr/gnu/bin/cp -p" truncates nanosecond part during copying a file.
> you can set the GNUCOPY variable, or rebase to m106 where configure should
> find it automatically.
Surfing in the Internet, I have devised a silly, pragmatic workaround.
1. Truncate sub-second part of all files in the module svx:
$ find svx -type f | xargs perl -e 'map{ $t=(stat($_))[9]; utime($t,$t,$_) } @ARGV'
$ stat svx/inc/svx/sxsoitm.hxx
...
Access: 2011-02-22 20:59:42.000000000 +0900
Modify: 2011-02-22 20:59:42.000000000 +0900
Change: 2011-04-07 03:58:23.672122611 +0900
2. Do the same thing on the target files, just one time:
$ find $OUTDIR/inc/svx -type f | xargs perl -e 'map{ $t=(stat($_))[9]; utime($t,$t,$_) } @ARGV'
3. Give it a try:
$ make -sr deliverlog
[ build LOG ] svx
Yahhoooo, "make" abandons complaining about .LOW_RESOLUTION_TIME.
That is, I know, just for fun. :-)
Best regards,
Tora
--
-----------------------------------------------------------------
To unsubscribe send email to [email protected]
For additional commands send email to [email protected]
with Subject: help