This patch changes the behavior of the version.sh script under Darwin/MacOS X to match with CygWin,Linux and BSD/OS; that is, the resulting VERSION macro will contain the date of the last change of the file CVS/Entries.
On Saturday, 06 November 2004 at 22:06, Chris Roccati wrote:
This patch changes the behavior of the version.sh script under Darwin/MacOS X to match with CygWin,Linux and BSD/OS; that is, the resulting VERSION macro will contain the date of the last change of the file CVS/Entries.
Looks like a terrible overkill to me. Can't this be done with date? Is MOX really that broken? And since you're calling awk several times, couldn't you make it once? R. -- MPlayer RPMs maintainer: http://greysector.rangers.eu.org/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"
On 7 Nov 2004, at 00:48, Dominik 'Rathann' Mierzejewski wrote:
Looks like a terrible overkill to me. Can't this be done with date?
Nope: the BSD date simply returns the current date. So does Solaris. So does HP-UX.
Is MOX really that broken? And since you're calling awk several times, couldn't you make it once?
It's not a matter of being broken. It's a matter of date being just date. I simply copied and adapted the code from BSD/OS (already present in the same script), and given the limited use of this script (just once per ./configure) I think there's no need to spend time in optimizing it.
On Sat, Nov 06, 2004 at 10:06:31PM +0100, Chris Roccati wrote:
This patch changes the behavior of the version.sh script under Darwin/MacOS X to match with CygWin,Linux and BSD/OS; that is, the resulting VERSION macro will contain the date of the last change of the file CVS/Entries.
Committed something based on this patch that uses cut instead of awk. Diego
On May 18, 2005, at 23:54 , Diego Biurrun wrote:
On Sat, Nov 06, 2004 at 10:06:31PM +0100, Chris Roccati wrote:
This patch changes the behavior of the version.sh script under Darwin/MacOS X to match with CygWin,Linux and BSD/OS; that is, the resulting VERSION macro will contain the date of the last change of the file CVS/Entries. Committed something based on this patch that uses cut instead of awk.
F.Y.I. does not work with Mac OS X 10.4.x
On Thu, May 19, 2005 at 10:13:17PM +0200, Chris Roccati wrote:
On May 18, 2005, at 23:54 , Diego Biurrun wrote:
On Sat, Nov 06, 2004 at 10:06:31PM +0100, Chris Roccati wrote:
This patch changes the behavior of the version.sh script under Darwin/MacOS X to match with CygWin,Linux and BSD/OS; that is, the resulting VERSION macro will contain the date of the last change of the file CVS/Entries. Committed something based on this patch that uses cut instead of awk.
F.Y.I. does not work with Mac OS X 10.4.x
Please elaborate, works fine here on 10.3.9... Diego
On Fri, May 20, 2005 at 01:40:34AM +0200, Diego Biurrun wrote:
On Thu, May 19, 2005 at 10:13:17PM +0200, Chris Roccati wrote:
On May 18, 2005, at 23:54 , Diego Biurrun wrote:
On Sat, Nov 06, 2004 at 10:06:31PM +0100, Chris Roccati wrote:
This patch changes the behavior of the version.sh script under Darwin/MacOS X to match with CygWin,Linux and BSD/OS; that is, the resulting VERSION macro will contain the date of the last change of the file CVS/Entries. Committed something based on this patch that uses cut instead of awk.
F.Y.I. does not work with Mac OS X 10.4.x
Please elaborate, works fine here on 10.3.9...
To be precise: What does 10.4 print for "ls -lT CVS/Entries"? Diego
On May 20, 2005, at 13:38 , Diego Biurrun wrote:
This patch changes the behavior of the version.sh script under Darwin/MacOS X to match with CygWin,Linux and BSD/OS; that is, the resulting VERSION macro will contain the date of the last change of the file CVS/Entries. Committed something based on this patch that uses cut instead of awk. F.Y.I. does not work with Mac OS X 10.4.x Please elaborate, works fine here on 10.3.9... To be precise: What does 10.4 print for "ls -lT CVS/Entries"?
ls -lT CVS/Entries returns: "-rw-r--r-- 1 chris staff 3413 May 19 20:11:09 2005 CVS/Entries" so the result in last_cvs_update is "0500May-20:11" There's something totally wrong in using something like: last_cvs_update=`perl -e 'use POSIX qw(strftime); print strftime "%y% m%d-%H:%M\n", localtime((stat "CVS/Entries")[9])'`
On Fri, May 20, 2005 at 08:48:12PM +0200, Chris Roccati wrote:
There's something totally wrong in using something like: last_cvs_update=`perl -e 'use POSIX qw(strftime); print strftime "%y% m%d-%H:%M\n", localtime((stat "CVS/Entries")[9])'`
I don't understand, what are you trying to say here? Diego
On May 20, 2005, at 21:23 , Diego Biurrun wrote:
On Fri, May 20, 2005 at 08:48:12PM +0200, Chris Roccati wrote:
There's something totally wrong in using something like: last_cvs_update=`perl -e 'use POSIX qw(strftime); print strftime "%y% m%d-%H:%M\n", localtime((stat "CVS/Entries")[9])'`
I don't understand, what are you trying to say here?
What I'm trying to say is why try to cope with the apparently endless variations of output from the various version of ls, using arcane incantations based on cut/awk/sed/whatever, when a single line of perl will do? Expecially considering that perl is provided in almost every unix- like currently available?
On Fri, May 20, 2005 at 09:54:13PM +0200, Chris Roccati wrote:
On May 20, 2005, at 21:23 , Diego Biurrun wrote:
On Fri, May 20, 2005 at 08:48:12PM +0200, Chris Roccati wrote:
There's something totally wrong in using something like: last_cvs_update=`perl -e 'use POSIX qw(strftime); print strftime "%y% m%d-%H:%M\n", localtime((stat "CVS/Entries")[9])'`
I don't understand, what are you trying to say here?
What I'm trying to say is why try to cope with the apparently endless variations of output from the various version of ls, using arcane incantations based on cut/awk/sed/whatever, when a single line of perl will do?
You're not seriously claiming that cut/awk/sed/etc are more obscure than Perl, are you? ;-)
Expecially considering that perl is provided in almost every unix- like currently available?
Almost is not good enough. MPlayer runs on platforms where Perl is not necessarily available. But the main problem is that it would add another dependency to MPlayer when we try to keep external dependencies down. I'm going to ignore OS X 10.3 since its ls is clearly buggy, so our problem is solved already anyway. Diego
On May 21, 2005, at 16:23 , Diego Biurrun wrote:
Expecially considering that perl is provided in almost every unix- like currently available?
Almost is not good enough. MPlayer runs on platforms where Perl is not necessarily available. But the main problem is that it would add another dependency to MPlayer when we try to keep external dependencies down.
I understand. Anyway, perl is *always* available under MacOS X 10.x and Darwin, so the case label for Darwin we could use it and avoid current and future problems.
On 21 May 2005, at 16:23 , Diego Biurrun wrote:
I'm going to ignore OS X 10.3 since its ls is clearly buggy, so our problem is solved already anyway.
The current version.sh from the CVS "almost works", with both Mac OS X 10.4.x 10.3.x. The attached patch (which should be harmless for "the rest of the world") fixes everything.
On Thu, Jun 02, 2005 at 09:42:22PM +0200, Chris Roccati wrote:
On 21 May 2005, at 16:23 , Diego Biurrun wrote:
I'm going to ignore OS X 10.3 since its ls is clearly buggy, so our problem is solved already anyway.
The current version.sh from the CVS "almost works", with both Mac OS X 10.4.x 10.3.x. The attached patch (which should be harmless for "the rest of the world") fixes everything.
Not here (OS X 10.3.9): ./version.sh: line 1: printf: 0.666667: invalid number ./version.sh: line 1: printf: Jun: invalid number #define VERSION "dev-CVS-050000-15:35" Patch rejected. Diego
On 4 Jun 2005, at 15:39 , Diego Biurrun wrote:
The current version.sh from the CVS "almost works", with both Mac OS X 10.4.x 10.3.x. The attached patch (which should be harmless for "the rest of the world") fixes everything.
Not here (OS X 10.3.9):
I assumed it "almost worked" both on 10.3 and 10.4. In fact does not work on either, just in different ways... It turns out that 10.3.x ls says "-rw-r--r-- 1 chris staff 3413 2 Jun 21:29:35 2005 CVS/Entries" whereas 10.4.x ls says "-rw-r--r-- 1 chris staff 3413 Jun 2 21:29:35 2005 CVS/Entries". Without the patch, no error is generated, but the output string is wrong: under 10.4, if the day of the month is less than 10 the version string is yymmd-hh:mm under 10.3, the version string is always yy00Mon-hh:mm This patch uses a perl version of the incantation if the os is Darwin. There's ALWAYS perl with darwin.
On Sat, Jun 04, 2005 at 07:10:09PM +0200, Chris Roccati wrote:
I assumed it "almost worked" both on 10.3 and 10.4. In fact does not work on either, just in different ways... It turns out that 10.3.x ls says "-rw-r--r-- 1 chris staff 3413 2 Jun 21:29:35 2005 CVS/Entries" whereas 10.4.x ls says "-rw-r--r-- 1 chris staff 3413 Jun 2 21:29:35 2005 CVS/Entries".
Yes, ls on 10.3 is buggy when it comes to the effects locale is supposed to have on date strings.
Without the patch, no error is generated, but the output string is wrong: under 10.4, if the day of the month is less than 10 the version string is yymmd-hh:mm
Fixed.
under 10.3, the version string is always yy00Mon-hh:mm
10.3 is buggy, as outlined above.
This patch uses a perl version of the incantation if the os is Darwin. There's ALWAYS perl with darwin.
I'm torn about this. Yes, it's only one line and it does work, even on 10.3, but it does add another dependency and our policy has always been not to work around environment bugs unless absolutely necessary. Any more opinions? Diego
Hello, again... On 5 Jun 2005, at 16:21 , Diego Biurrun wrote:
I'm torn about this. Yes, it's only one line and it does work, even on 10.3, but it does add another dependency and our policy has always been not to work around environment bugs unless absolutely necessary.
Ok, let's see if you like this one better: no perl and only a small workaround for OS X 10.3.x.
On Sun, Jun 05, 2005 at 06:28:18PM +0200, Chris Roccati wrote:
On 5 Jun 2005, at 16:21 , Diego Biurrun wrote:
I'm torn about this. Yes, it's only one line and it does work, even on 10.3, but it does add another dependency and our policy has always been not to work around environment bugs unless absolutely necessary.
Ok, let's see if you like this one better: no perl and only a small workaround for OS X 10.3.x.
OK, you got me there. Applied with a few slight modifications, thanks. Diego
participants (5)
-
Chris Roccati -
Chris Roccati -
Diego Biurrun -
Dominik 'Rathann' Mierzejewski -
Il Demone Guardiano