On Fr, 2009-01-16 at 20:51 +0300, Vitaly Lipatov wrote:
version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD2>/dev/null || echo "wine-@PACKAGE_VERSION@") | sed -n -e '$$s/(.* )/const char wine_build[] = "\1";/p'` && (echo $$version | cmp -s - $@) || echo $$version >$@ || ($(RM) $@ && exit 1)
version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD2>/dev/null || echo "@PACKAGE_NAME@ @PACKAGE_VERSION@")
Your patch change also the minus to a space
В сообщении от 16 января 2009 Detlef Riekenberg написал(a):
On Fr, 2009-01-16 at 20:51 +0300, Vitaly Lipatov wrote:
version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD2>/dev/null || echo "wine-@PACKAGE_VERSION@") | sed -n -e '$$s/(.* )/const char wine_build[] = "\1";/p'` && (echo $$version | cmp -s - $@) || echo $$version >$@ || ($(RM) $@ && exit 1)
version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD2>/dev/null || echo "@PACKAGE_NAME@ @PACKAGE_VERSION@")
Your patch change also the minus to a space
Wine 1.1.13 looks more correctly than wine-1.1.13, or not?
On Sa, 2009-01-17 at 14:24 +0300, Vitaly Lipatov wrote:
В сообщении от 16 января 2009 Detlef Riekenberg написал(a):
On Fr, 2009-01-16 at 20:51 +0300, Vitaly Lipatov wrote:
version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD2>/dev/null || echo "wine-@PACKAGE_VERSION@") | sed -n -e '$$s/(.* )/const char wine_build[] = "\1";/p'` && (echo $$version | cmp -s - $@) || echo $$version >$@ || ($(RM) $@ && exit 1)
version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD2>/dev/null || echo "@PACKAGE_NAME@ @PACKAGE_VERSION@")
Your patch change also the minus to a space
Wine 1.1.13 looks more correctly than wine-1.1.13, or not?
No. Even Wine-1.1.13 is dangerous, because unix is case dependent.
Try "git describe HEAD" for reference The echo is used only as fallback, when "git describe HEAD" failed
You change the output of wine --version. - A very high risk, that you break scripts, because of the space - A high risk, that you break scripts, because of the different case.
You change the output of winetest - Did you checked, that the parse script on winehq still works?
For changing "Wine" to wine", you can pipe through 'tr "W" "w"', when every supported system has a working "tr".
В сообщении от 17 января 2009 Detlef Riekenberg написал(a):
On Sa, 2009-01-17 at 14:24 +0300, Vitaly Lipatov wrote:
В сообщении от 16 января 2009 Detlef Riekenberg написал(a):
On Fr, 2009-01-16 at 20:51 +0300, Vitaly Lipatov wrote:
version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD2>/dev/null || echo "wine-@PACKAGE_VERSION@") | sed -n -e '$$s/(.* )/const char wine_build[] = "\1";/p'` && (echo $$version | cmp -s - $@) || echo $$version >$@ || ($(RM) $@ && exit 1)
version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD2>/dev/null || echo "@PACKAGE_NAME@ @PACKAGE_VERSION@")
Your patch change also the minus to a space
Wine 1.1.13 looks more correctly than wine-1.1.13, or not?
No. Even Wine-1.1.13 is dangerous, because unix is case dependent.
Try "git describe HEAD" for reference The echo is used only as fallback, when "git describe HEAD" failed
Well, you are accepted echo is used only as fallback.
You change the output of wine --version.
- A very high risk, that you break scripts, because of the space
- A high risk, that you break scripts, because of the different case.
What script can check wine version for wine if this name is not changed for ages? Are you know an example of such script? I know only one wine related script, it is winetricks :)
You change the output of winetest
- Did you checked, that the parse script on winehq still works?
I guess parse scripts works with wine built from git, and echo fallback is not used in any case.
For changing "Wine" to wine", you can pipe through 'tr "W" "w"', when every supported system has a working "tr".
PACKAGE_NAME can be some another name, no Wine nor wine.
Vitaly Lipatov wrote:
В сообщении от 17 января 2009 Detlef Riekenberg написал(a):
On Sa, 2009-01-17 at 14:24 +0300, Vitaly Lipatov wrote:
В сообщении от 16 января 2009 Detlef Riekenberg написал(a):
On Fr, 2009-01-16 at 20:51 +0300, Vitaly Lipatov wrote:
version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD2>/dev/null || echo "wine-@PACKAGE_VERSION@") | sed -n -e '$$s/(.* )/const char wine_build[] = "\1";/p'` && (echo $$version | cmp -s - $@) || echo $$version >$@ || ($(RM) $@ && exit 1)
version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD2>/dev/null || echo "@PACKAGE_NAME@ @PACKAGE_VERSION@")
Your patch change also the minus to a space
Wine 1.1.13 looks more correctly than wine-1.1.13, or not?
No. Even Wine-1.1.13 is dangerous, because unix is case dependent.
Try "git describe HEAD" for reference The echo is used only as fallback, when "git describe HEAD" failed
Well, you are accepted echo is used only as fallback.
You change the output of wine --version.
- A very high risk, that you break scripts, because of the space
- A high risk, that you break scripts, because of the different case.
What script can check wine version for wine if this name is not changed for ages? Are you know an example of such script? I know only one wine related script, it is winetricks :)
You change the output of winetest
- Did you checked, that the parse script on winehq still works?
I guess parse scripts works with wine built from git, and echo fallback is not used in any case.
For changing "Wine" to wine", you can pipe through 'tr "W" "w"', when every supported system has a working "tr".
PACKAGE_NAME can be some another name, no Wine nor wine.
Excuse me, Vitaly. What was an initial purpose of this change?
В сообщении от 17 января 2009 Nikolay Sivov написал(a):
PACKAGE_NAME can be some another name, no Wine nor wine.
Excuse me, Vitaly. What was an initial purpose of this change?
I suppose to remove hardcoded project name for support build wine based project with other name. For example, I build modified wine for ALT Linux distro and my users wish to make difference between original wine and modified wine.
And it is stange to have PACKAGE_NAME and do not use it. Like magic numbers in a source code.
"Vitaly Lipatov" lav@etersoft.ru wrote:
PACKAGE_NAME can be some another name, no Wine nor wine.
Excuse me, Vitaly. What was an initial purpose of this change?
I suppose to remove hardcoded project name for support build wine based project with other name. For example, I build modified wine for ALT Linux distro and my users wish to make difference between original wine and modified wine.
Unless you have a dedicated bugzilla and plan to handle all the bug reports for your builds please don't ship Wine with custom patches.
On 18 января 2009, Dmitry Timoshkov wrote:
"Vitaly Lipatov" lav@etersoft.ru wrote:
...
For example, I build modified wine for ALT Linux distro and my users wish to make difference between original wine and modified wine.
Unless you have a dedicated bugzilla and plan to handle all the bug reports for your builds please don't ship Wine with custom patches.
Dimitry, we are in minus sign against space discussion, not wine shipping an bug reporting :)
Also welcome to out bugzillas: https://bugzilla.altlinux.org/enter_bug.cgi?product=Sisyphus http://bugs.etersoft.ru/enter_bug.cgi?product=Wine%20School http://bugs.etersoft.ru/enter_bug.cgi?product=WINE%40Etersoft
Can I ship wine with custom patches now? :)
On Saturday 17 January 2009 15:21:26 Detlef Riekenberg wrote:
On Sa, 2009-01-17 at 14:24 +0300, Vitaly Lipatov wrote:
В сообщении от 16 января 2009 Detlef Riekenberg написал(a):
On Fr, 2009-01-16 at 20:51 +0300, Vitaly Lipatov wrote:
version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD2>/dev/null || echo "wine-@PACKAGE_VERSION@") | sed -n -e '$$s/(.* )/const char wine_build[] = "\1";/p'` && (echo $$version | cmp -s - $@) || echo $$version >$@ || ($(RM) $@ && exit 1)
version=`(GIT_DIR=$(TOPSRCDIR)/.git git describe HEAD2>/dev/null || echo "@PACKAGE_NAME@ @PACKAGE_VERSION@")
Your patch change also the minus to a space
Wine 1.1.13 looks more correctly than wine-1.1.13, or not?
No. Even Wine-1.1.13 is dangerous, because unix is case dependent.
Try "git describe HEAD" for reference The echo is used only as fallback, when "git describe HEAD" failed
You change the output of wine --version.
- A very high risk, that you break scripts, because of the space
- A high risk, that you break scripts, because of the different case.
You change the output of winetest
- Did you checked, that the parse script on winehq still works?
For changing "Wine" to wine", you can pipe through 'tr "W" "w"', when every supported system has a working "tr".
What about using the standard @PACKAGE_TARNAME@ which is by default normalized (spaces removed, converted to lowercase, some other unsafe characters converted) by autoconf in AC_INIT?
@PACKAGE_TARNAME@-@PACKAGE_VERSION@ is used as a base for tarball/zip/etc. by many packages.
Paul Chitescu
В сообщении от 17 января 2009 Paul Chitescu написал(a):
For changing "Wine" to wine", you can pipe through 'tr "W" "w"', when every supported system has a working "tr".
What about using the standard @PACKAGE_TARNAME@ which is by default normalized (spaces removed, converted to lowercase, some other unsafe characters converted) by autoconf in AC_INIT?
It is a good idea to use PACKAGE_TARNAME, but only if we need tarname in wine --version output :) Does anyone know what is wine --version purpose if not for human read?
On Sat, Jan 17, 2009 at 12:31 PM, Vitaly Lipatov lav@etersoft.ru wrote:
В сообщении от 17 января 2009 Paul Chitescu написал(a):
For changing "Wine" to wine", you can pipe through 'tr "W" "w"', when every supported system has a working "tr".
What about using the standard @PACKAGE_TARNAME@ which is by default normalized (spaces removed, converted to lowercase, some other unsafe characters converted) by autoconf in AC_INIT?
It is a good idea to use PACKAGE_TARNAME, but only if we need tarname in wine --version output :) Does anyone know what is wine --version purpose if not for human read?
Again, can be used in scripts, many of which aren't public.
Austin English wrote:
On Sat, Jan 17, 2009 at 12:31 PM, Vitaly Lipatov lav@etersoft.ru wrote:
В сообщении от 17 января 2009 Paul Chitescu написал(a):
For changing "Wine" to wine", you can pipe through 'tr "W" "w"', when every supported system has a working "tr".
What about using the standard @PACKAGE_TARNAME@ which is by default normalized (spaces removed, converted to lowercase, some other unsafe characters converted) by autoconf in AC_INIT?
It is a good idea to use PACKAGE_TARNAME, but only if we need tarname in wine --version output :) Does anyone know what is wine --version purpose if not for human read?
Again, can be used in scripts, many of which aren't public.
Adding to Austin's input. The output of wine --version on my Mac results in: wine --version wine-1.1.8
This could be used as the input to a number of scripts and programs that may or may not be version dependent. Most of the script writers would do a cut on the hyphen. Removing it would break the script. There have been several suggestions on what to do to fix this so I am not going to go over them a second time. I would ask that the hyphen remain. Otherwise this is a good patch that allows for project name variation.
James McKenzie
В сообщении от 18 января 2009 Austin English написал(a):
On Sat, Jan 17, 2009 at 12:31 PM, Vitaly Lipatov lav@etersoft.ru wrote:
В сообщении от 17 января 2009 Paul Chitescu написал(a):
For changing "Wine" to wine", you can pipe through 'tr "W" "w"', when every supported system has a working "tr".
What about using the standard @PACKAGE_TARNAME@ which is by default normalized (spaces removed, converted to lowercase, some other unsafe characters converted) by autoconf in AC_INIT?
It is a good idea to use PACKAGE_TARNAME, but only if we need tarname in wine --version output :) Does anyone know what is wine --version purpose if not for human read?
Again, can be used in scripts, many of which aren't public.
I guess it is mythical task to check wine version if a new version released every two week.
Well, I think I have to fill a bugreport about incorrect output for --version option. A normal program prints version information, not tarball name as wine does.
An example:
$ dosbox --version
DOSBox version 0.72, copyright 2002-2007 DOSBox Team.
DOSBox is written by the DOSBox Team (See AUTHORS file)) DOSBox comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain condition.
-
Austin English -
Detlef Riekenberg -
Dmitry Timoshkov -
James McKenzie -
Nikolay Sivov -
Paul Chitescu -
Vitaly Lipatov