Topics

Matching QuantLib's compilation flags

dick.r.chiang@...
 

Greetings and salutations,

Premise: If I install QuantLib from github source, then `install.packages("RQuantLib")` should just work

We should continue to rely on `quantlib-config` to ensure our compiler flags match those of parent QuantLib.
Since `R CMD config CXX11STD`, i.e., "-std=gnu++11" is not default QuantLib, we should avoid assuming this in Makevars.in.

Takeaway: Do we want to turn off the vast majority of users who are not ubuntu-18.04 just to enforce "-std=gnu++11" compilation?

Dirk Eddelbuettel
 

On 23 December 2018 at 06:21, dick.r.chiang@... wrote:
| Greetings and salutations,
|
| Premise: If I install QuantLib from github source, then `install.packages("RQuantLib")` should just work

It does.

(You did not mention that you choose a particularly old distribution, Ubuntu
16.04, for which you need to compile QuantLib by adding the C++11 flag. Same
is true for Windows users.)

| We should continue to rely on `quantlib-config` to ensure our compiler flags match those of parent QuantLib.

I had thought about quantlib-config too but it does not seem to encode
compilation standards. Maybe because on my system I get C++11/C++14 for
free:

edd@rob:~$ quantlib-config --cflags
-I/usr/include -fopenmp
edd@rob:~$

| Since `R CMD config CXX11STD`, i.e., "-std=gnu++11" is not default QuantLib, we should avoid assuming this in Makevars.in.

You confuse R compile time options with _R package_ compile time options.

A bazillion packages on CRAN opt into C++11, some even into C++14.

R itself does not use C++ so you cannot expect it to be prescriptive for C++
standards.

| Takeaway: Do we want to turn off the vast majority of users who are not ubuntu-18.04 just to enforce "-std=gnu++11" compilation?

Please consider that the package as is is perfectly clean at CRAN:
https://cloud.r-project.org/web/checks/check_results_RQuantLib.html
(apart from the missing library for macOS which some volunteers are working
which is greatly appreciated).

As I told you already at GitHub, I do not think there is an issue here. *You*
chose to stick with an older OS release. Fine. That impacts your local
compilation. Thinking that that use case would require a change in the
package is simply not true. The package builds fine as is (particularly on
Linux and OSs that have a QuantLib library). As it has for maybe 15 years.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | @edd