On Thu, Apr 02, 2015 at 04:38:13PM +0000, Kavanagh, Mark B wrote: > > >On 04/01/15 at 07:45am, Kavanagh, Mark B wrote: > >> > >> >What's wrong with setting CFLAGS on the "configure" or "make" command > >> >line? This is the standard way to do this with Automake and Autoconf. > >> > > >> > >> Sure. However, setting CFLAGS on the command line overwrites any values > >> CFLAGS has > >attained via the 'configure' step. The most obvious symptom of this is > >significantly > >degraded performance, due to the fact that the optimization flags passed to > >CFLAGS during > >'configure' are overwritten by the command line value of CFLAGS. > > > >That should not be the case at all. 9562639 fixed this and stores > >the flags collected by configure in OVS_CFLAGS while the user can > >specify his own CFLAGS. > > > >If there is a bug, let's fix the bug. > > Hi Thomas, > > I have little experience of automake, so apologies for any shortcomings in my > understanding in this response. > > I've done quite a bit of testing on this, and have observed that > whenever CFLAGS are passed to 'make' on the command line (building > against DPDK), the performance degrades by ~3x; this leads me to > believe that the existing value of CFLAGS (namely -O2 -g) has been > overwritten by its command line counterpart.
Yes, if you supply your own CFLAGS then you have to supply -O2 -g, if you want them. You can leave them out, if you do not want them. Those are the only CFLAGS that are ever supplied automatically. > With respect to 9562639, I don't see where OVS_CFLAGS obtains its > initial value (i.e. existing CFLAGS). I've made a slight modification, > and found that it resolves the issue - maybe you could comment as to > the validity of the changes? OVS_CFLAGS is used in addition to CFLAGS, not as a substitute for it, so it should not include $CFLAGS. All of this is the standard way to use Autoconf and Automake. I might do things differently, if I were to invent my own way of doing things, since these conventions are somewhat weird in my opinion, but as long as we continue to use them I think it is best to honor their conventions. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
