On Sat, Mar 24, 2012 at 08:47:28PM +0100, Simon Ruderich wrote: > On Sat, Mar 24, 2012 at 12:11:31PM -0700, Steve Langasek wrote:
> > What's the argument for patching all of the upstream rules files to read > > CPPFLAGS, instead of simply injecting our CPPFLAGS contents into CFLAGS? > Because it's the correct way to handle the flags. CFLAGS are for > the compiler, CPPFLAGS for the preprocessor. That's not a practical argument, it's a pedantic one. The compiler and the preprocessor have the same name, 'gcc', and passing CPPFLAGS to it is never going to cause a problem. > And by patching it upstream other distributions and users won't have to do > the same to correct this non-standard behavior and can just rely on the > flags working as they should. There's no standard here; both approaches have been in common usage for decades. > > I'm probably going to do the latter unless there's a good (practical) > > argument not to in this case. > Both ways work fine. If the build system is complex and difficult > to fix I'd also suggest injecting CPPFLAGS into CFLAGS. But as > it's easy to fix in this case (and you already have a finished > patch ready to be sent to the upstream devs and for > debian/patches/) I think it's a good idea to fix the real problem > - the upstream build system. Well, I don't care enough about getting this particular issue fixed upstream to deal with it, nor am I willing to carry a local patch for it. I've patched debian/rules to pass CPPFLAGS as part of CFLAGS for this package; I'm happy to undo that later if someone changes the upstream build system. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: Digital signature
