On 16/05/11 20:47, Ralf Wildenhues wrote:
> Hi Pádraig,
>
> * Pádraig Brady wrote on Mon, May 16, 2011 at 04:44:42PM CEST:
>> On 14/05/11 09:07, Paul Eggert wrote:
If something treats symlink mtime as significant,
then I suspect that it's at fault.
>>>
>>> Yes, there's something busted t
On 05/16/11 12:47, Ralf Wildenhues wrote:
> GNU make, I presume.
I checked GNU make 3.82's source code, and I didn't
see how it could be a problem with GNU make, as it uses
stat, not lstat, for target timestamps. Perhaps I misread
the code, but I think it more likely the problem is elsewhere.
(So
Hi Pádraig,
* Pádraig Brady wrote on Mon, May 16, 2011 at 04:44:42PM CEST:
> On 14/05/11 09:07, Paul Eggert wrote:
> >> If something treats symlink mtime as significant,
> >> then I suspect that it's at fault.
> >
> > Yes, there's something busted there. GNU 'make' does the right thing:
> > it f
On 05/16/2011 01:40 PM, Paul Eggert wrote:
> lswords=`ls -1diL "$src" "$dst" 2>/dev/null` &&
> inum= && \
> for lsword in $lswords; do
> case $lsword in
> *[!0-9]*) ;;
> *) if test -z "$inum"; then
> inum=$lsword
>elif test $inum -ne $lsword; then
>inum=
>
On 05/16/11 12:12, Eric Blake wrote:
> On the other hand, it only works with POSIX
> shells (Solaris /bin/sh doesn't understand the XSI notion of %% and ##).
>
Another option might be something like this (untested)
lswords=`ls -1diL "$src" "$dst" 2>/dev/null` &&
inum= && \
for lsword in $lswords
On 05/16/2011 12:57 PM, Jim Meyering wrote:
> Paul Eggert wrote:
>> On 05/16/11 07:44, Pádraig Brady wrote:
>>> I tested your ls ordering trick on linux, solaris 10 and freebsd and it
>>> works.
>>> Please push.
>>
>> Thanks, done.
>
> Thanks. I appreciate the added comments, too ;-)
>
> What d
Paul Eggert wrote:
> On 05/16/11 07:44, Pádraig Brady wrote:
>> I tested your ls ordering trick on linux, solaris 10 and freebsd and it
>> works.
>> Please push.
>
> Thanks, done.
Thanks. I appreciate the added comments, too ;-)
What do you think of this addition?
It may be more efficient to in
On 05/16/11 07:44, Pádraig Brady wrote:
> I tested your ls ordering trick on linux, solaris 10 and freebsd and it works.
> Please push.
Thanks, done.
On 14/05/11 09:07, Paul Eggert wrote:
>> If something treats symlink mtime as significant,
>> then I suspect that it's at fault.
>
> Yes, there's something busted there. GNU 'make' does the right thing:
> it follows symlinks when checking time stamps. Is some other 'make'
> is being used, or per
On 05/14/2011 02:41 AM, Jim Meyering wrote:
>> But this won't work if the file names contain spaces.
>
> Good point. But this does:
>
> inums=`ls -1diL "$src" "$dst" 2>/dev/null|sed 's/ .*//'` && set $inums &&
> test "$1" = "$2" || {
>
> However, it could still fail for any name containing
Paul Eggert wrote:
>> If something treats symlink mtime as significant,
>> then I suspect that it's at fault.
>
> Yes, there's something busted there. GNU 'make' does the right thing:
> it follows symlinks when checking time stamps. Is some other 'make'
> is being used, or perhaps some tool othe
> If something treats symlink mtime as significant,
> then I suspect that it's at fault.
Yes, there's something busted there. GNU 'make' does the right thing:
it follows symlinks when checking time stamps. Is some other 'make'
is being used, or perhaps some tool other than 'make'?
> That looks
Pádraig Brady wrote:
> I've noticed a few times when re-running bootstrap
> within my coreutils directory, that the build will fail because
> it seems that the timestamps of the symlinks in m4/ are used,
> rather than those of the target m4 files.
>
> For example recently, @HAVE_SIGHANDLER_T@ was l
I've noticed a few times when re-running bootstrap
within my coreutils directory, that the build will fail because
it seems that the timestamps of the symlinks in m4/ are used,
rather than those of the target m4 files.
For example recently, @HAVE_SIGHANDLER_T@ was left unsubstituted in
lib/signal.
14 matches
Mail list logo
