Hi Jeff,
Jeff Squyres wrote:
> I see that there was a patch committed on this, but I think it's not
> quite right, specifically in the Makefile.am area.
>
> In the top-level Makefile.am, the following statement was added:
>
> cd libltdl && $(MAKE) local-install-files
>
> However, there's no
I see that there was a patch committed on this, but I think it's not
quite right, specifically in the Makefile.am area.
In the top-level Makefile.am, the following statement was added:
cd libltdl && $(MAKE) local-install-files
However, there's no such target in libltdl/Makefile.am (nor
l
Peter O'Gorman wrote:
> Hi Gary,
Hallo!
> I question that we can rely on tar being installed, although I have not
> come across a system where it isn't. Please backport things to
> branch-1-5, it is apparently the branch that never dies, no matter how
> much we want it to.
Good point. Maybe I s
Gary V. Vaughan wrote:
> Peter O'Gorman wrote:
> > I question that we can rely on tar being installed, although I have not
> > come across a system where it isn't.
>
> Maybe I should add a --no-tar option to fallback to 'cp -p'
> to cover that eventuality?
I take it back. GCS allows us to rely on
Gary V. Vaughan wrote:
No, Please don't! I think using this idiom will work correctly everywhere
(untested however!):
( cd $sourcedir && tar cf - filenames; ) | ( cd $destdir && tar xf -; )
I'll try and make a patch for branch-2-0 and HEAD today, and we can backport
that to branch-1-5 if necessar
Hi Peter!
Peter O'Gorman wrote:
> Jeff Squyres wrote:
> | If this is true, then even if -p is portable, it potentially won't solve
> | the problem. :-\
> |
>
> While it may not solve the problem on all platforms, it is unlikely to
> cause
> harm and may fix some platforms.
This just masks the r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Squyres wrote:
| If this is true, then even if -p is portable, it potentially won't solve
| the problem. :-\
|
While it may not solve the problem on all platforms, it is unlikely to cause
harm and may fix some platforms. I did some tests on my sys
On Feb 17, 2005, at 12:59 PM, Albert Chin wrote:
From the autoconf manual:
Commands like `cp -p' and `touch -r' typically do not copy file
timestamps to their full resolutions (*note Limitations of Usual
Tools::). Hence you should be wary of rules like this:
dest: src
On Wed, Feb 16, 2005 at 11:43:00PM +0900, Peter O'Gorman wrote:
> Brian Barrett wrote:
>
> >Could libtoolize just use 'cp -f -p' instead of 'cp -f' when copying the
> >files and leave the timestamps as they are in the original libltdl
> >directory? I admit to not understanding all the details,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter O'Gorman wrote:
| I'm just googling cp -p portability actually, on first inspection it
| seems like this is a no-brainer. I'll google some more to find out why
| we're wrong :)
If you're in a timezone that is currently awake, send a patch to -patc
Brian Barrett wrote:
Could libtoolize just use 'cp -f -p' instead of 'cp -f' when copying the
files and leave the timestamps as they are in the original libltdl
directory? I admit to not understanding all the details, but that was
enough to clear up the problem for me (as one would expect - the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Squyres wrote:
| I have found a bug in libtoolize which has bit me for a long, long time
| but I've never gotten around to checking it out (it was a minor
| annoyance). But today, it bit one of my other developers in a rather
| awkward m
On Feb 16, 2005, at 9:28 AM, Peter O'Gorman wrote:
| Some suggestions for a fix:
|
| 1. Do the copy as now, but then have a series of "touch" statements
to
| modify the mtime/ctime all the relevant AM-specific files in the
Right
| Order so that the timestamps will be proper.
|
| 2. Copy the files
I have found a bug in libtoolize which has bit me for a long, long time
but I've never gotten around to checking it out (it was a minor
annoyance). But today, it bit one of my other developers in a rather
awkward moment. So I guess it's time to investigate and report this
bug.
14 matches
Mail list logo
