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 :-)
/Bruce