Re: [Rd] a plead to package developers regarding GCC
Andy, Are you talking about C or Fortran code here? Fortran has `intrinsics', C does not AFAIK. I think we do pretty strict checking of C code in CRAN packages, and I have not encountered problems with other C compilers (e.g. the Solaris ones). There used to be issues with CRLF line endings, but we check those now. There are a lot of Fortran issues. One is that neither g77 nor gfortran claim to be standards-conformant compilers: g77 is said to compile `GNU Fortran'. Several packages are known not to be Fortran 77 and have been reported to the developers (usually with no response). I tend to use the Solaris compilers to check Fortran, but it is less rigorous than the tests we manage on C code. (And done less systematically, although the R tarball is checked on a wide range of compilers.) There are a dozen or so packages with problems wih 64-bit issues (all of which were reported to the maintainers long ago). We do suggest is that you report specific problems to the relevant package maintainers. They are probably unaware of the issues, and some have been very responsive. If there are some generic issues we can add to the checking process please let us have ideas (offline if you prefer), similar to the CRLF issue mentioned above. Brian On Tue, 6 Jun 2006, Liaw, Andy wrote: > Dear DevelopeRs, > > I'd like to ask those who develop R packages with compiled code to please > try avoiding dependency on GCC (gcc/g77/gfortran/g++) specific features in > the code, for the simple reason that there are non-GCC compilers out there > that might choke on such features. > > I found this out back when I was trying to build R-2.3.0-to-be on our dual > Opteron based Scyld cluster. Because the GCC that shipped with the current > Scyld is too old for building R properly on that architecture, we ended up > using the Portland Group compilers (PGI 6.1). After some update in the R > source, I got R to build and pass make check-all. However, when installing > contributed packages on CRAN, quite a few failed. I manually checked a > handful, and found that some of the code defined some basic math functions > that conflicts with intrinsics. Removal of such code enable me to build and > run package checks on them successfully. I believe many of such cases stem > from the fact that the code were originally from the output of g2c. f2c? > I can try to post a more concrete example if needed. I think resolving this > will facilitate wider use of these packages. > > Thanks for your consideration. > > Best, > Andy > > Andy Liaw, PhD > Biometrics ResearchPO Box 2000 RY33-300 > Merck Research LabsRahway, NJ 07065 > andy_liaw(a)merck.com 732-594-0820 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Wishlist: Writing R Extensions suggestions RE: [R] vague errors on R CMD check for very minimal S4-style package (PR#8944)
Ah yes. There they are right on page 4 of "Writing R Extensions". The "LazyLoad: yes" was sufficient to avoid the check errors, but I'll add the "Depends: methods" as well. For the manual-impaired like me, it _may_ be worth reiterating these two requirements in section 1.6.6 "Name spaces with formal classes and methods" - right where the .onLoad requirement is mentioned. Also, at may be worth mentioning in "Writing R Extensions" that the stats4 package can serve as a template/example for S4-style packages (at least a quick search for "stats4" didn't find anything there or in the FAQ). Thanks to you both. -Steve >This is an S4-using package but missing a dependence on 'methods'. > >To run R CMD check the package has to load under minimal conditions, e.g. > >R_DEFAULT_PACKAGES=NULL R >... >> library(foo) > >should work. 'methods' is quite expensive to load, and so is only used in >checking if explicitly requested. >> Try adding LazyLoad: yes to DESCRIPTION (or SaveImage: yes). >> >And > >Depends: methods > >Package stats4 is provided in part as an example of a small S4-using >package for people to copy. * Steve Roels, Ph.D. Senior Scientist I Computational Biology Phone: (617) 761-6820 Millennium Pharmaceuticals, Inc.FAX: (617) 577-3555 640 Memorial Drive Email: [EMAIL PROTECTED] Cambridge, MA 02139-4815 * This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] build R with Visual Studio
Prof Brian Ripley wrote: > On Tue, 6 Jun 2006, Jennifer Lai wrote: > >> Hi, >>Has anyone had success in building R source with Visual Studio? I >> followed the instructions in README.packages, but failed on the very >> first step, where it's looking for R.dll. I looked through R source and >> couldn't find the file. Can someone point me to where this file is >> located or generated? Thanks! > > > R.dll is the main file generated, and the first step is to build > Rpwd.exe. > Do you really mean the R source? Yes, I would like to build the entire R source using Visual Studio instead of MinGW. Visual Studio seems the only way to build a 64-bit R currently. However, to go get there, I thought I'll try building a 32-bit version first. Regards, Jennifer > > People have built R for Windows with Visual Studio (using their own > projects/makefiles and other tools to generate .def files) but it did > not work correctly. It seems that the IEC60559 (aka IEEE754) > compliance of VC++ was not adequate -- as I recall it thought -Inf > 3. > > This isn't the list for such programming questions: R-devel would be > more appropriate. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sort() generic? [Re: Suspicious behaviour of sort on POSIXct ..]
{Diverted to R-devel}
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Tue, 6 Jun 2006 21:14:01 +0100 (BST) writes:
BDR> On Tue, 6 Jun 2006, [EMAIL PROTECTED]
BDR> wrote:
>> Hi ,
>>
>> When I sort a vector of POSIXct values in R-2.3.0 and
>> R-2.3.1, I get a vector of numeric values and this gets
>> some of my code to crash (class object creation). Is that
>> a R bug?
BDR> No, it is as documented: see ?sort
BDR> As from R 2.3.0, all attributes are removed from
BDR> the return value except names, which are sorted. (If
BDR> 'partial' is specified even the names are removed.)
BDR> Note, the class is an attribute. For many classes
BDR> sorting destroys the appropriateness of the class.
Indeed, and I agree this a good change.
However, the above also suggests that ideally, sort() would be
a generic function.
One good reason for sort() not being generic now is the fact
that method dispatch costs a bit, *and* that we like sort() to
be really fast.
One way to achieve a generic sort() and keep the possibility of
of very fast sort() --- similarly to rep() and rep.int()
would be to rename the current sort into something like
sortNum() {"Num" for numeric}, make sort() into a generic,
and replace sort() by sortNum() in those code parts which need
to remain optimally fast.
>> In the mean time. I'll try to override the sort function
>> for the POSIXct objects.
BDR> You can restore the class if appropriate.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] further f77/gfortran
OK: despite Dirk's very kind help, I decided that trying to deal with R configuration and Debian configuration simultaneously was too difficult. I did manage to solve my problem by reconfiguring/making/ installing all of 2.3.1 from source: ./configure F77=/usr/bin/g77 make make install A few questions inspired by this experience: (1) it seems a bit odd that R sets F77=gfortran by default, since the system has both g77 and gfortran compilers on it, and given that there is a separate variable (FC) for the Fortran 90/95 compiler -- does it make any sense to switch the search order in configure so that g77 comes up first if present? (2) I couldn't figure out a way to set the F77 variable on a per-package basis: adding a src/Makevars file or a configure file to the package didn't seem to help, but perhaps I didn't put it in the right place/get it exactly right. Any clues? cheers Ben Bolker -- 620B Bartram Hall[EMAIL PROTECTED] Zoology Department, University of Floridahttp://www.zoo.ufl.edu/bolker Box 118525 (ph) 352-392-5697 Gainesville, FL 32611-8525 (fax) 352-392-3704 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] PATCH: fix for bug 7924
Hi,
Since no one answered my questions about the "theoretically correct
values of named for that LANGSXP object, I made an assumption that
the problem was in the creation of the call2 object to begin with.
Yes, the bug was there.
Inline is the patch to fix bug 7924.
It seems that in subset.c in do_subset_dflt, if the final object is a
LANGSXP object we allocate a new object and copy from the just
allocated result VECSXP object to a list style object (to make it a
LANGSXP object) but we forgot to copy over the NAMED value as well so
we were leaving it basically blank and ignoring all of the logic in
ExtractSubset and VectorSubset that actually determined the proper
named value in the first place.
Here is the patch. With this patch in place, the test case passes.
Hopefully we can now close bug 7924
[EMAIL PROTECTED] R]$ cat bug_7924_fix.patch
--- src/main/subset.c.keep 2006-06-07 09:58:26.0 -0400
+++ src/main/subset.c 2006-06-07 11:49:40.0 -0400
@@ -675,6 +675,7 @@
setAttrib(ans, R_DimSymbol, getAttrib(ax, R_DimSymbol));
setAttrib(ans, R_DimNamesSymbol, getAttrib(ax,
R_DimNamesSymbol));
setAttrib(ans, R_NamesSymbol, getAttrib(ax, R_NamesSymbol));
+ SET_NAMED(ans,NAMED(ax));
}
else {
PROTECT(ans);
Kevin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] further f77/gfortran
On 7 June 2006 at 11:44, Ben Bolker wrote:
| OK: despite Dirk's very kind help, I decided that
Yeah, kind but still not useful to you. No cigar yet :)
| trying to deal with R configuration and Debian configuration
| simultaneously was too difficult.
[ I'd still like to learn from useRs what I could do to make the Debian
package more appealing. Local rebuilds seems natural to me; I do that eg on
the Ubuntu boxen at work to combine 'stability' ('frozen' outer system) with
'current' apps where I need and what them. By keeping those within the
package management framework, I feel I combine the best of two worlds. YMMV. ]
| I did manage to solve my problem by reconfiguring/making/
| installing all of 2.3.1 from source:
|
| ./configure F77=/usr/bin/g77
| make
| make install
|
|A few questions inspired by this experience:
|
| (1) it seems a bit odd that R sets F77=gfortran
| by default, since the system has both g77 and gfortran
| compilers on it, and given that there is a separate
| variable (FC) for the Fortran 90/95 compiler --
| does it make any sense to switch
| the search order in configure so that g77 comes up first if present?
|
| (2) I couldn't figure out a way to set the F77 variable
| on a per-package basis: adding a src/Makevars file or a configure
| file to the package didn't seem to help, but perhaps I didn't
| put it in the right place/get it exactly right. Any clues?
That came up recently:
a) ~/.Makevars (as I recall)
b) on a per invocation basis:
MAKEFLAGS="FFLAGS=-O1" R CMD INSTALL ...
is something that worked for me.
That said, I personally still dislike that I cannot 'undo' the settings the
R's global Makeconf. I'd love to turn debugging, optimisation, ... on/off on
demand.
Dirk
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] further f77/gfortran
On Wed, 7 Jun 2006, Ben Bolker wrote: > > OK: despite Dirk's very kind help, I decided that > trying to deal with R configuration and Debian configuration > simultaneously was too difficult. > > I did manage to solve my problem by reconfiguring/making/ > installing all of 2.3.1 from source: > > ./configure F77=/usr/bin/g77 > make > make install > > A few questions inspired by this experience: > > (1) it seems a bit odd that R sets F77=gfortran > by default, since the system has both g77 and gfortran > compilers on it, and given that there is a separate > variable (FC) for the Fortran 90/95 compiler -- > does it make any sense to switch > the search order in configure so that g77 comes up first if present? That's not what is happening, I believe. If the C compiler is gcc4, it preferentially picks gfortran, as gcc4 and g77 are not compatible on structures such as double complex on at least some architectures. From the R.m4 file ## * If the C compiler is gcc, we try looking for a matching GCC Fortran ## compiler (gfortran for 4.x, g77 for 3.x) first. This should handle ## problems if GCC 4.x and 3.x suites are installed and, depending on ## the gcc default, the "wrong" GCC Fortran compiler is picked up (as We used to pick a F77 compiler first, but note that all legal F77 code is legal F95 code so there was no actual advantage is doing so. The issue here is that your code is not legal F77, and g77 (which implements 'GNU Fortran') is letting it through. > (2) I couldn't figure out a way to set the F77 variable > on a per-package basis: adding a src/Makevars file or a configure > file to the package didn't seem to help, but perhaps I didn't > put it in the right place/get it exactly right. Any clues? You cannot override either F77 or the default .f.o rule, as etc/Makeconf wins. However, you set up a specific rule in Makevars, and also need an all: target. See fastICA/src/Makevars for the sort of thing. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] do developers need to assign rights to someone
Hi, Just in case this is an issue. I freely give all of my patches and changes to the R source code to whomever holds or keeps the copyright/ rights for this project. If it matters I have not signed any FSF agreements but I have done so with Sun for OpenOffice.org and would be willing to do so for this project. Thanks, Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sort() generic? [Re: Suspicious behaviour of sort on POSIXct ..]
On Wed, 7 Jun 2006, Martin Maechler wrote:
> {Diverted to R-devel}
>
>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>> on Tue, 6 Jun 2006 21:14:01 +0100 (BST) writes:
>
>BDR> On Tue, 6 Jun 2006, [EMAIL PROTECTED]
>BDR> wrote:
>>> Hi ,
>>>
>>> When I sort a vector of POSIXct values in R-2.3.0 and
>>> R-2.3.1, I get a vector of numeric values and this gets
>>> some of my code to crash (class object creation). Is that
>>> a R bug?
>
>BDR> No, it is as documented: see ?sort
>
>BDR> As from R 2.3.0, all attributes are removed from
>BDR> the return value except names, which are sorted. (If
>BDR> 'partial' is specified even the names are removed.)
>
>BDR> Note, the class is an attribute. For many classes
>BDR> sorting destroys the appropriateness of the class.
(An example BTW is a time series: the times associated with values would
be shuffled on sorting.)
> Indeed, and I agree this a good change.
> However, the above also suggests that ideally, sort() would be
> a generic function.
>
> One good reason for sort() not being generic now is the fact
> that method dispatch costs a bit, *and* that we like sort() to
> be really fast.
> One way to achieve a generic sort() and keep the possibility of
> of very fast sort() --- similarly to rep() and rep.int()
> would be to rename the current sort into something like
> sortNum() {"Num" for numeric}, make sort() into a generic,
> and replace sort() by sortNum() in those code parts which need
> to remain optimally fast.
The current sort handles much more than numeric vectors. I agree with
reasoning, but it seems wrong to ask all those using sort() in packages
to rename their usages (conditional on R >= 2.4.0) not to be penalized.
sort() is an interface to three C functions. It ought to be possible to
use internal dispatch for internal sort and (not for psort or qsort), for
which I believe the overhead would be acceptable. I think that is
acceptable: people who set partial or method must have read the help page.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] further f77/gfortran
On Wed, 7 Jun 2006, Dirk Eddelbuettel wrote:
>
> On 7 June 2006 at 11:44, Ben Bolker wrote:
> | OK: despite Dirk's very kind help, I decided that
>
> Yeah, kind but still not useful to you. No cigar yet :)
>
> | trying to deal with R configuration and Debian configuration
> | simultaneously was too difficult.
>
> [ I'd still like to learn from useRs what I could do to make the Debian
> package more appealing. Local rebuilds seems natural to me; I do that eg on
> the Ubuntu boxen at work to combine 'stability' ('frozen' outer system) with
> 'current' apps where I need and what them. By keeping those within the
> package management framework, I feel I combine the best of two worlds. YMMV. ]
>
> | I did manage to solve my problem by reconfiguring/making/
> | installing all of 2.3.1 from source:
> |
> | ./configure F77=/usr/bin/g77
> | make
> | make install
> |
> |A few questions inspired by this experience:
> |
> | (1) it seems a bit odd that R sets F77=gfortran
> | by default, since the system has both g77 and gfortran
> | compilers on it, and given that there is a separate
> | variable (FC) for the Fortran 90/95 compiler --
> | does it make any sense to switch
> | the search order in configure so that g77 comes up first if present?
> |
> | (2) I couldn't figure out a way to set the F77 variable
> | on a per-package basis: adding a src/Makevars file or a configure
> | file to the package didn't seem to help, but perhaps I didn't
> | put it in the right place/get it exactly right. Any clues?
>
> That came up recently:
>
> a) ~/.Makevars (as I recall)
~/.R/Makevars, but that applies to all packages on all builds.
> b) on a per invocation basis:
> MAKEFLAGS="FFLAGS=-O1" R CMD INSTALL ...
>is something that worked for me.
Yes, but it only works in some Makes, including GNU Make.
> That said, I personally still dislike that I cannot 'undo' the settings the
> R's global Makeconf. I'd love to turn debugging, optimisation, ... on/off on
> demand.
It might make sense to separate CFLAGS, FFLAGS, CXXFLAGS, FCFLAGS out of
etc/Makeconf into a Makefile included before Makevars. But I am very
reluctant to make it easy to change the F77 compiler or FLIBS or
FPICFLAGS.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] do developers need to assign rights to someone
Kevin B. Hendricks wrote: > Hi, > > Just in case this is an issue. I freely give all of my patches and > changes to the R source code to whomever holds or keeps the copyright/ > rights for this project. If it matters I have not signed any FSF > agreements but I have done so with Sun for OpenOffice.org and would > be willing to do so for this project. AFAIK there are only two common reasons for assigning-copying over (instead of having just a license notice saying somebody can do as he/she wish with your code as you intended) is (1) possible copyright infringement is imminent, and the R core team needs to sue somebody on your behalf (2) dual-license/commercial licensing - i.e. the R core team want to relicense R with a different license, then they need to have the copyright to do that. situation (1) is rather unlikely for R, but you never know - historically, the FSF uses that argument to request all changes to GCC to be signed over, I think. As for (2), Sun people for obvious reasons want to get you to sign over copyright, because they want to relicense the openoffice code under the commericial staroffice license. I don't think either (1) or (2) applies too closely to R, but then, this is just my opinion... HTL __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] further f77/gfortran
Prof Brian Ripley wrote:
> We used to pick a F77 compiler first, but note that all legal F77 code
> is legal F95 code so there was no actual advantage is doing so. The
> issue here is that your code is not legal F77, and g77 (which implements
> 'GNU Fortran') is letting it through.
Not that it matters:
from http://gcc.gnu.org/ml/fortran/2004-05/msg00308.html :
/* We have overlapping initializers. It could either be
+ partially initilalized arrays (lagal), or the user
+ specified multiple initial values (illegal).
+ We don't implement this yet, so bail out. */
+ gfc_todo_error ("Initialization of overlapping
variables");
so it's not clear to me whether my code is actually illegal,
or an odd case that gfortran doesn't handle ("yet") ...
the specific code that fails (as far as I can tell) is
INTEGER SMALL(2)
INTEGER LARGE(2)
INTEGER RIGHT(2)
INTEGER DIVER(2)
INTEGER LOG10(2)
C
REAL RMACH(5)
SAVE RMACH
C
EQUIVALENCE (RMACH(1),SMALL(1))
EQUIVALENCE (RMACH(2),LARGE(1))
EQUIVALENCE (RMACH(3),RIGHT(1))
EQUIVALENCE (RMACH(4),DIVER(1))
EQUIVALENCE (RMACH(5),LOG10(1))
http://www.fortran.com/F77_std/rjcnf-8.html#sh-8.2
suggests this should be legal as long as REALs are twice as long
as INTEGERs?
I'm on the edge of my knowledge here -- don't know if there's a better
idiom ...
cheers
Ben
--
620B Bartram Hall[EMAIL PROTECTED]
Zoology Department, University of Floridahttp://www.zoo.ufl.edu/bolker
Box 118525 (ph) 352-392-5697
Gainesville, FL 32611-8525 (fax) 352-392-3704
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] further f77/gfortran
On 7 June 2006 at 17:29, Prof Brian Ripley wrote: | > That came up recently: | > | > a) ~/.Makevars (as I recall) | | ~/.R/Makevars, but that applies to all packages on all builds. Yes indeed. Thanks for catching and correcting this. | > b) on a per invocation basis: | > MAKEFLAGS="FFLAGS=-O1" R CMD INSTALL ... | >is something that worked for me. | | Yes, but it only works in some Makes, including GNU Make. | | > That said, I personally still dislike that I cannot 'undo' the settings the | > R's global Makeconf. I'd love to turn debugging, optimisation, ... on/off on | > demand. | | It might make sense to separate CFLAGS, FFLAGS, CXXFLAGS, FCFLAGS out of | etc/Makeconf into a Makefile included before Makevars. But I am very | reluctant to make it easy to change the F77 compiler or FLIBS or | FPICFLAGS. Well, as that would cover my past needs (where on certain architectures we had switch from -O2 to a lower optimisation setting or g77 would die; obviously a g77 bug and now mostly (?) fixed) so I'd say yes. Not hugely pressing as the current system has worked, but I would at certain points in the past have like to have this available. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] further f77/gfortran
On Jun 7, 2006, at 10:22 AM, Dirk Eddelbuettel wrote: > > On 7 June 2006 at 17:29, Prof Brian Ripley wrote: > | > That came up recently: > | > > | > a) ~/.Makevars (as I recall) > | > | ~/.R/Makevars, but that applies to all packages on all builds. > > Yes indeed. Thanks for catching and correcting this. > > | > b) on a per invocation basis: > | > MAKEFLAGS="FFLAGS=-O1" R CMD INSTALL ... > | >is something that worked for me. > | > | Yes, but it only works in some Makes, including GNU Make. > | > | > That said, I personally still dislike that I cannot 'undo' the > settings the > | > R's global Makeconf. I'd love to turn debugging, > optimisation, ... on/off on > | > demand. > | > | It might make sense to separate CFLAGS, FFLAGS, CXXFLAGS, FCFLAGS > out of > | etc/Makeconf into a Makefile included before Makevars. But I am > very > | reluctant to make it easy to change the F77 compiler or FLIBS or > | FPICFLAGS. > > Well, as that would cover my past needs (where on certain > architectures we > had switch from -O2 to a lower optimisation setting or g77 would die; > obviously a g77 bug and now mostly (?) fixed) so I'd say yes. > > Not hugely pressing as the current system has worked, but I would > at certain > points in the past have like to have this available. I would really like the ability to override the optimization flags on a per package basis. I have a use case where I am using an SDK outside of my control which does not work with -O2 on (some versions of) GCC. From Dirk's description it seems I am not alone in having this problem. From my point of view it is unreasonable to make a user build R with specific optimization flags just because of a single package (especially if one wants to distribute the package to many users). I guess what I am trying to articulate is that I see this as a potential useful ability to have. Right now I am using a hack by Simon Urbanek posted to R-devel some time ago which basically reverses the order of PKG_CXXFLAGS and CXXFLAGS, allowing me to override the R supplied ones. I know this is not portable since -O* is not a common to all compilers. I am thinking of something like PKG_CXXSAFEFLAGS which - if set - will override the CXXFLAGS set by etc/Makeconf. Then I should be able to do something like (pseudo code) if using(gcc) set PKG_CXXSAFEFLAGS= I am not sure whether this is feasible, because I am only really interested in overriding the optimization flags and not all the other CXXFLAGS. Unfortunately, my knowledge of Makefiles and configure scripts do not make it possible to come up with a specific suggestion - only a use case and a wish :) /Kasper > Dirk > > > -- > Hell, there are no rules here - we're trying to accomplish something. > -- Thomas A. Edison > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] PATCH: fix for bug 7924
On Wed, 7 Jun 2006, Kevin B. Hendricks wrote: > > Inline is the patch to fix bug 7924. > Yes, that seems to fix it. Committed. -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
