It has been a few months since I was doing this for the 4.9.3 windows
toolchain, but the best way I found IIRC of getting everything working was
to install msys2 and use that as the build environment, but put the proper
Rtools toolchain first in the PATH.
On Mon, Aug 15, 2016 at 9:13 AM, Hadley Wi
One other option is to include the src for libmagic inside your
package, and use that as a fallback if it's not installed on the
system. That gives linux users what they want (linking to the system
package), and windows users what they want (it just works). It only
works for simple libraries, but i
On 13 August 2016 at 18:19, Bob Rudis wrote:
| Aye. I rly need to get back to my security & privacy "R" post. The
| slipstreaming in of these binaries is somewhat frightening. Almost as
| frightening as being stuck on Windows 😀
Right.
And the Windows side of that so-called "anticonf" [1] pattern
Aye. I rly need to get back to my security & privacy "R" post. The
slipstreaming in of these binaries is somewhat frightening. Almost as
frightening as being stuck on Windows 😀
On Sat, Aug 13, 2016 at 13:09 Dirk Eddelbuettel wrote:
>
> I don't think there is a good "generally applicable" solution
I don't think there is a good "generally applicable" solution. We have a
bunch of hacks. Below are three quickly picked examples from packages of mine:
RQuantLib relies on environment variables and a 'library that needs to just
be there' on the build host:
## The environment variable QUANTLI
Hey folks,
I usually stare in awe at the C-backed packages that rely on eternal
libraries which are super-easy to get working on macOS & *nix _but_ that
also work perfectly on Windows. I fire up Windows (*maybe*) once a month to
test some of my packages but I'm curious as to what I need to do to s
