[dpdk-dev] [PATCH] scripts: fix symbol overriding in configuration files
bruce.richardson at intel.com
Fri Nov 28 15:37:53 CET 2014
On Fri, Nov 28, 2014 at 03:06:11PM +0100, David Marchand wrote:
> Hello Bruce,
> On Fri, Nov 28, 2014 at 2:56 PM, Bruce Richardson <
> bruce.richardson at intel.com> wrote:
> > On Thu, Nov 27, 2014 at 10:17:22AM -0800, Thomas Monjalon wrote:
> > > > When redefining the same symbol in configuration (basically after an
> > inclusion),
> > > > we need to undefine the previous symbol to avoid "redefined" errors.
> > > >
> > > > Signed-off-by: David Marchand <david.marchand at 6wind.com>
> > >
> > > Acked-by: Thomas Monjalon <thomas.monjalon at 6wind.com>
> > >
> > > Applied
> > >
> > This patch doesn't seem to work on FreeBSD. I'm still investigating how to
> > fix
> > it but right now compilation with gcc/clang on FreeBSD is broken due to the
> > config.h file having lines like the below in it :-(
> > /usr/home/bruce/
> > dpdk.org/x86_64-native-bsdapp-clang/include/rte_config.h:3:21: fatal
> > error: extra tokens at end of #undef directive [-Wextra-tokens]
> > #undef RTE_EXEC_ENVn#define RTE_EXEC_ENV "bsdapp"
> This is probably because of the \n in the sed.
> Can you try something like this (I did not like this version of my patch at
> first because it is not that readable) ?
> diff --git a/scripts/gen-config-h.sh b/scripts/gen-config-h.sh
> index 2fac08c..d36efd6 100755
> --- a/scripts/gen-config-h.sh
> +++ b/scripts/gen-config-h.sh
> @@ -35,9 +35,11 @@ echo "#ifndef __RTE_CONFIG_H"
> echo "#define __RTE_CONFIG_H"
> grep CONFIG_ $1 |
> grep -v '^[ \t]*#' |
> -sed 's,CONFIG_\(.*\)=y.*$,#undef \1\n#define \1 1,' |
> +sed 's,CONFIG_\(.*\)=y.*$,#undef \1\
> +#define \1 1,' |
> sed 's,CONFIG_\(.*\)=n.*$,#undef \1,' |
> -sed 's,CONFIG_\(.*\)=\(.*\)$,#undef \1\n#define \1 \2,' |
> +sed 's,CONFIG_\(.*\)=\(.*\)$,#undef \1\
> +#define \1 \2,' |
> sed 's,\# CONFIG_\(.*\) is not set$,#undef \1,'
> echo "#endif /* __RTE_CONFIG_H */"
I tried a number of different things to get sed to introduce "\n" characters,
but I missed trying that one. I've sent on an alternative fix now, which uses
tr instead of sed to insert the "\n"'s. It's not a fix I'm terribly happy with,
but having seen the above (but not tried it yet), it actually doesn't seem that
bad in comparison :-)
More information about the dev