hi, i need some hep from some rpm experts!:-( i spend way too much time with it so please someone tell me the reason. suppose i write into mingw32-macros.mingw32: --------------------------------------- %_mingw32_cflags -O2 -g --------------------------------------- the values are not important just there is no line break in it, but if i write: --------------------------------------- %_mingw32_cflags -O2 \\ -g --------------------------------------- the compile, install etc and: VAR="`rpm --eval %{_mingw32_cflags}`";set|grep VAR then the outputs: --------------------------------------- VAR=$'-O2 \\n -g ' VAR='-O2 -g' --------------------------------------- ^^^ you see if there is a line break then there is an extra "$" at the beginning! why? and how can i remove it? it's not a problem here, but it's a real pain for much longer and complicated macro. thanks in advance. yours.
On Wed, Nov 19, 2008 at 02:23:18PM +0100, Farkas Levente wrote:
the compile, install etc and: VAR="`rpm --eval %{_mingw32_cflags}`";set|grep VAR then the outputs:
VAR=$'-O2 \\n -g ' VAR='-O2 -g'
^^^ you see if there is a line break then there is an extra "$" at the beginning!
Take it one step at a time:
$ rpm --eval %{_mingw32_cflags} -O2 -g -pipe -Wall \ -Wp,-D_FORTIFY_SOURCE=2 \ -fexceptions \ --param=ssp-buffer-size=4
$ var='a \
b'
$ echo $var a \ b
$ set | grep var var=$'a \\nb'
If you read the manual page to bash you'll see that $'string' is a special form of quoting which allows certain backslash-escaped characters to be used, eg. \n for newline.
So the literal value of $var is:
a <space> <backslash> <newline> b
Anyway, what are you actually trying to achieve? I'm assuming this is part of your plan to combine /etc/rpm/macros.mingw32 and /usr/bin/mingw32-configure into a single script. This is an admirable goal because it reduces duplication, but if it means using some massively complex shell hackery instead, then the cure might be worse than the disease.
I'd prefer to see a patch which keeps the duplication, if that's going to be quicker.
Rich.
Richard W.M. Jones wrote:
Anyway, what are you actually trying to achieve? I'm assuming this is part of your plan to combine /etc/rpm/macros.mingw32 and /usr/bin/mingw32-configure into a single script. This is an admirable goal because it reduces duplication, but if it means using some massively complex shell hackery instead, then the cure might be worse than the disease.
I'd prefer to see a patch which keeps the duplication, if that's going to be quicker.
ok so here is the current state of the patch and a few comments. - add a few more path macros just to be complete - put into one line the _mingw32_cflags because currently during compile it look very ugly with the line beaks in all gcc command line - add a _mingw32_env macro with define all useful enviroment variable to be able to use at different places (if you like i can explain all variable) - rewrite _mingw32_configure to use the env and use all configure options - add _mingw32_make and _mingw32_makeinstall macros actually we've got projects which not use autoconf just a makefile, but like to compile it without problems.
in this case i can add a new one liner file mingw32-scripts.sh into libexec like: $(rpm --eval "%{_"`basename $0|tr "-" "_"`"}") and create symlinks in bin to this file as mingw32-configure, mingw32-make, mingw32-env and these can be run. so every script can use macros.mingw32, but currently not working:-(
On Wed, Nov 19, 2008 at 03:01:56PM +0100, Farkas Levente wrote:
Richard W.M. Jones wrote:
Anyway, what are you actually trying to achieve? I'm assuming this is part of your plan to combine /etc/rpm/macros.mingw32 and /usr/bin/mingw32-configure into a single script. This is an admirable goal because it reduces duplication, but if it means using some massively complex shell hackery instead, then the cure might be worse than the disease.
I'd prefer to see a patch which keeps the duplication, if that's going to be quicker.
ok so here is the current state of the patch and a few comments.
- add a few more path macros just to be complete
- put into one line the _mingw32_cflags because currently during compile
it look very ugly with the line beaks in all gcc command line
- add a _mingw32_env macro with define all useful enviroment variable to
be able to use at different places (if you like i can explain all variable)
- rewrite _mingw32_configure to use the env and use all configure options
- add _mingw32_make and _mingw32_makeinstall macros
actually we've got projects which not use autoconf just a makefile, but like to compile it without problems.
Yup, I cannot see any problem with that patch. Except you need to add -mms-bitfields to the mingw32-configure shell script too so that they are kept the same.
Do you want to apply the patch, or would you like me to do it?
in this case i can add a new one liner file mingw32-scripts.sh into libexec like: $(rpm --eval "%{_"`basename $0|tr "-" "_"`"}") and create symlinks in bin to this file as mingw32-configure, mingw32-make, mingw32-env and these can be run. so every script can use macros.mingw32, but currently not working:-(
Honestly, don't worry about this. Just keep the duplication for now.
Rich.
Richard W.M. Jones wrote:
On Wed, Nov 19, 2008 at 03:01:56PM +0100, Farkas Levente wrote:
Richard W.M. Jones wrote:
Anyway, what are you actually trying to achieve? I'm assuming this is part of your plan to combine /etc/rpm/macros.mingw32 and /usr/bin/mingw32-configure into a single script. This is an admirable goal because it reduces duplication, but if it means using some massively complex shell hackery instead, then the cure might be worse than the disease.
I'd prefer to see a patch which keeps the duplication, if that's going to be quicker.
ok so here is the current state of the patch and a few comments.
- add a few more path macros just to be complete
- put into one line the _mingw32_cflags because currently during compile
it look very ugly with the line beaks in all gcc command line
- add a _mingw32_env macro with define all useful enviroment variable to
be able to use at different places (if you like i can explain all variable)
- rewrite _mingw32_configure to use the env and use all configure options
- add _mingw32_make and _mingw32_makeinstall macros
actually we've got projects which not use autoconf just a makefile, but like to compile it without problems.
Yup, I cannot see any problem with that patch. Except you need to add -mms-bitfields to the mingw32-configure shell script too so that they are kept the same.
Do you want to apply the patch, or would you like me to do it?
in this case i can add a new one liner file mingw32-scripts.sh into libexec like: $(rpm --eval "%{_"`basename $0|tr "-" "_"`"}") and create symlinks in bin to this file as mingw32-configure, mingw32-make, mingw32-env and these can be run. so every script can use macros.mingw32, but currently not working:-(
Honestly, don't worry about this. Just keep the duplication for now.
for me that's the most annoying thing:-( that's why i do the whole stuff. so probably on friday i'll have some free time to find the reason why not work. while this works: rpm --eval %{_mingw32_configure}>out;chmod +x out;./out i can't find any other "in script" solution to run the output of rpm --eval:-(
OK, I talked to Dan and I'm going to apply the patch, plus make the minor fix to mingw32-configure.
Rich.
On Wed, Nov 19, 2008 at 03:01:56PM +0100, Farkas Levente wrote:
+%_mingw32_build %{_mingw32_host}
[...]
- --build=%{_mingw32_build} \\
Actually no, this bit was wrong, and I have reverted it. The build system is the Fedora machine. The host system is the machine where the binary is going to run (Windows). The target is the type of binaries that the binary operates on.
Rich.
-
Farkas Levente -
Richard W.M. Jones