[Rd] src/Makevars ignored ?

[Bob Rudis]

You're then asking CRAN to violate your "ideal contract" w/r/t compiler
switching inside src/Makevars since CRAN needs to setup and produce
standard, predictable, repeatable builds, including binary generation for
two platforms (much to Dirk's chagrin, there _are_ other operating systems
besides Debian linux ;-)

I wouldn't want CRAN to honor said compiler switching inside src/Makevars
but the way you're describing the perceived contract, you're implying they
should.

I totally understand your posit, but there's a larger universe to consider
than internal package builds. In a sense you really want an R version of
Rule of Acquisition #17 "A contract is a contract is a contract... but only
on my internal systems." and that doesn't seem like a good idea to me when
the larger universe of CRAN and the need for baseline standard package
builds are considered.



On Tue, Sep 27, 2016 at 11:19 AM, Kasper Daniel Hansen <
kasperdanielhansen at gmail.com> wrote:

> So now we have some important context for your original question.
>
> I understand why you want "symmetry" but because of the reasons Dirk
> outlines, I personally think it is a bad idea, ie. I disagree with your
> statement "anyway I still convinced that if R provides a mechanisn
> hierachical way of variable overwrite pkg / user/ system it _SHOULD_ be
> consistent at all levels".
>
> The mechanism for achieving what you want - overriding CC on a local
> machine -  is using a ~/.R/Makevars file.  I am not sure that this can be
> done in a package specific manner (I don;t do this very often), but you
> could create this file ('this file" being ~/.R/Makevars), install the
> package and then remove it.  Remember, this is an install-time setting, so
> you don't need the users of your system to be involved in this. That way
> you could test your proposed fix.  If the fix works, it seems to me like it
> should be included in the package source by the package maintainer, perhaps
> using a configure script, but that is ultimately something which is up to
> the package maintainer.
>
> Best,
> Kasper
>
> On Tue, Sep 27, 2016 at 10:52 AM, Eric Deveaud <edeveaud at pasteur.fr>
> wrote:
>
> > Le 27/09/16 à 16:17, Kasper Daniel Hansen a écrit :
> >
> >> As a package author, it is in my opinion irresponsible to override these
> >> system settings (which is why it is also impossible).  You have no idea
> >> what system it is being deployed on,
> >>
> >
> > as the it guy dedicated to install and maintain softs on our cluster I
> > have a reasonable knowledge of the systems I work on.
> >
> > I don't want to distribute any of the piece of code I was asked to made
> > available on the cluster.
> > I just need (and succeded plus functional test succeded) to build the
> > Rpackage requested by a specific software.
> >
> >
> > I mean, you don't even know if the
> >> compiler is gcc.If a user wants (say) heavy optimization they will
> >> compile R with optimization.  (For this reason I also don't think users
> >> should modify their ~/.R/Makevars, unless for testing purposes).
> >>
> >
> > my question was not in a R package developer context, but in the R user
> > that grabs some piece of code and is not abble to compile it because of
> > 1) a developper that mixed C and C++ code which is legit.
> > 2) a silly interaction beetween C and C++ symbol generation because of
> the
> > use, in our case, of CC = gcc -std=gnu99
> > 3) a dev that answwer: "I have no clue, in debian it works" ;-(
> >
> > anyway I still convinced that if R provides a mechanisn hierachical way
> of
> > variable overwrite pkg / user/ system it _SHOULD_ be consistent at all
> > levels
> >
> > my question was raised because of our install mechanism that (hopefully)
> > does not allow
> > modification of files like ~/.R/Makevars.
> > I can only "play" with the sources of the software it is working on
> > and//or environment variables. so I wanted  to have a temporary way of
> > setting CC to be plain gcc without ISO C99 language standard support just
> > for this specific R library.
> >
> >
> > The exception is (in my opinion) if you need to decrease the level of
> >> optimization because you know or suspect the compiler to generate wrong
> >> code.
> >>
> >> What you should do, is use
> >>   PKG_CFLAGS
> >> as documented in R-exts, 1.2.1 under "Using Makevars".
> >>
> >
> > in the documentation you pointed (and trust me I read it), keyword is
> _set
> > additional_  preprocessor options and//or compiler flags
> >
> > only way to _remove_ is to overwrite
> >
> > back to logic.
> >
> > either Makevars, whatever level, allow to overwrite CC definition
> > either Makevars, whatever level, disable CC redefinition
> >
> > but not a mix
> >
> >
> >         Eric
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]