Compilation time about rvinecopulib HOT 6 CLOSED

Generally, I don't think there's huge potential for speedup. Most of the slowness (at least for me) came with all these freaking compiler warnings from RcppEigen and BH. Now to the solutions:

1. We should definitely allow for LinkingTo.
2. That's an option.
3. Don't think we can do much here. Things that aren't used shouldn't be compiled anyway afaik.

How about putting the header only version in inst/include, but putting the shared lib headers in src/include/, the cpps in src/ and building the shared lib from there? We can't use the headers of inst/include ourselves though, because then we would define functions multiple times.

from rvinecopulib.

1. I'm not convinced. It's a pretty specific (as opposed to general purpose) library.
2. OK.
3. For instance, we don't need to include the vine headers in the bicop wrappers, but if you're right about the not used/not compiled, it does not matter indeed.

from rvinecopulib.

1. Yeah, but stuff like vinereg I would have written in C++ with a LinkingTo if that option would have existed back then. And at least I intend to do similar things that way in the future. If one cannot use the headers via LinkinTo, one always has to include all vinecopulib headers as part of any other package.

from rvinecopulib.

1. Yeah, vinereg and eecop are examples that comes to mind, but even us didn't link again the vinecopulib headers ;) Also, are you sure that we can't link against the functions in vinecopulib if the headers are in inst and the library is compiled in a "standard" way ?

from rvinecopulib.

1. Apparently there is no other way when using custom C++ classes.
2. Using a single wrapper file brought down compilation time from ~1m45s to ~45s on my machine (single core). I think that's reasonable, so I would vote for this option.

from rvinecopulib.

See #124

from rvinecopulib.