Re: Debhelper for R packages
On 9 September 2016 at 15:14, Gordon Ball wrote:
| On 09/09/16 14:17, Dirk Eddelbuettel wrote:
| > | The plan was to avoid seeing eg, lintian hardening-no-bindnow warnings
| > | on packages with compiled extensions. I tried injecting dpkg-buildflags
| > | LDFLAGS output into the MAKEFLAGS environment for R CMD INSTALL but it
| > | doesn't appear to work. It is possible this is also not particularly
| > | important (and/or might interfere with R's own build config) - I don't
| > | really see security as a major R issue.
| >
| > It's an R issue. R "remembers" CC, CFLAGS, CXX, CXXFLAGS, etc pp from its
| > configure run and reuses them. When R runs 'R CMD INSTALL' you can add to
| > this on a per-package basis via the PKG_* variants from inside the package.
| > But we can't override from the outside. Minor annoyance (ie would be nice to
| > strip '-g' sometimes, toggle -O2 for -O3, ...). Needs an upstream change.
|
| I understood (from how the CDBS makefile worked) that you could set an
| env var MAKEFLAGS encapsulating other build flags and it would be used.
| I was trying to use the same mechanism, ie
|
| MAKEFLAGS=LDFLAGS=-z,now R CMD INSTALL ...
|
| Is this mechanism no longer useable (or have I misunderstood what it
| should be able to do)?
Maybe. Let me revise to a "possibly". I think at a minimum you'd want "+=" to
not clobber LDFLAGS from R's Makeconf (on Debian in /etc/R/Makeconf -- do a
grep for LDFLAGS there, it is pretty fine frained...)
| Yes, I've read #752609 and I think I understood your meaning - that
| anything coming directly from CRAN/bioconductor should have fairly
| strong guarantees of correctness, and re-checking that at build time is
| extra unnecessary work for us.
Right. I don't want to say "don't do it" -- do whatever floats your boat --
but the marginal benefit may well be a lot lower than for other package
families. That said, 'more tests' never make anything worse (apart maybe
from (ab)using a lot of human and system resources).
| (Although I suspect there must be some edge cases we might nevertheless
| catch at build-time, I can't admittedly come up with a concrete one
| right now).
We agree. It is possible, though maybe less likely. In that sense,
additional work may be better spent on, say, this debhelperization. Or
figuring out how to help with repro or ...
| > | I am wondering if this should be interpreted as a tight dependency on
| > | the LinkingTo: package, eg
| > |
| > | Built-Using: r-cran-rcpp (=version) or
| > | Depends: r-cran-rcpp (=version)
| >
| > No.
| >
| > | or if we need to trigger a transition when a package which can be the
| > | subject of LinkingTo: changes.
| >
| > No.
| >
| > | I'm speculating a bit here - I don't know how often this is a
| > | problem/how stable in practice package ABIs are. This might just be
| > | adding more work for a rare problem.
| >
| > Yes.
|
| That's a nice easy answer to those questions, thanks. No special
| treatment of this header needed, then.
I think a true C++ expert once explained a corner case to me where this does
matter and we'd need transitions etc pp -- I forget the details -- but I am
fairly positive we do _NOT_ need transitions etc in general for this.
Compile-time header use is more like static library use and orthogonalizes
things a little. It is a real advantage.
Later, Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: