On Sun, Nov 03, 2013 at 10:24:26AM -0600, Dirk Eddelbuettel wrote: > > On 3 November 2013 at 16:03, Julian Gilbey wrote: > | > They do no harm, and make explicit what we do. > | > > | > I think that is a plus. It also standard GNU autotools behaviour. > | > | Fair enough. I'm not sure I understand what you mean by "It also > | standard ...". It is unlikely to do harm. > > In the > > configure; make; make install CFLAGS="-O3 -Wall" > > being extremely common. Yes, CFLAGS can also be set in the call to > configure, but the way make works, it picks up env vars too, which is how we > have been doing the install (eg debian/... instead of /usr) redicrect since > whenever.
Ah, I hear what you're saying. In the case of R, all of the Makefiles include a configure-generated Makefile fragment which sets all of the variables configured during the configure phase, including CFLAGS etc., so in the case of R (but not necessarily in any other package), these extra CFLAGS=... are redundant (but not harmful). > | The patch essentially breaks down into two distinct things: > | > | (1) Replacing the special casing of all the architectures by a call to > | dpkg-buildflags. > > I am not sure that dpkg-buildflags will magically spew out all the special > cases for R which I accumulated over a decade. > > I'd rather keep them. Fair enough, though it may be that some of the arch-specific cases are no longer needed. One way to find out might be to upload with a vanilla use of dpkg-buildflags and then fix precisely those architectures which break. But that might be more effort than it's worth. And see next comment.... > So my idea would be to start the cflags etc variables by dpkg-buildflags and > then append as needed per architecture. Worst case it fails as we have > conflicting statements (-O3 ... -O0) in the same string. Do you know if > order is left to right, or first wins, or ... ? I don't know the answer to this. I had a quick look at both the gcc documentation and gcc source, and I'm as clueless as I was before I looked. :-( > | (2) Removing the explicit variable setting on the make invocations. > | > | The patch is longer because I've left the old versions in as comments. > > Acknowledged. My main beef is (1) above, and the desire for rather minimal > change. I understand this - it sounds very wise. > | Go for it! > > Keep pushing to keep me honest :) :-) > | When the next version of dpkg is uploaded, the FFLAGS bug will be > | fixed, and then dpkg-buildflags --get FFLAGS will give the correct > | output; my current patch uses CFLAGS for fflags as well. > > Ok. Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
