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 < kasperdanielhan...@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 <edeve...@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@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel