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
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]]
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]]