From edd at debian.org  Tue Mar  7 15:51:03 2017
From: edd at debian.org (Dirk Eddelbuettel)
Date: Tue, 7 Mar 2017 08:51:03 -0600
Subject: [Rd] Platform dependent native routine registration
In-Reply-To: <CABtg=K=21nKnxtEWDTqafXGxTo8Ke_ET8Kh=SDRsd67N_oUQxw@mail.gmail.com>
References: <CABtg=KkBqR3+FGPUwaHA4UF=V7fqkhCmvGiKTZ=x3UPP4YRbiQ@mail.gmail.com>
	<22718.51054.27893.394368@max.eddelbuettel.com>
	<CABtg=K=21nKnxtEWDTqafXGxTo8Ke_ET8Kh=SDRsd67N_oUQxw@mail.gmail.com>
Message-ID: <22718.51415.299096.672599@max.eddelbuettel.com>


On 7 March 2017 at 14:47, G?bor Cs?rdi wrote:
| On Tue, Mar 7, 2017 at 2:45 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
| [...]
| >
| > Could you resort to preprocessor conditioning to only compile the code
| > relevant for a particular platform while hiding away the inapplicable parts?
| 
| Yes, I do exactly that. The problem is that the R code still has
| 
| .Call(c_non_existent_function_on_this_platform, ...)
| 
| and R CMD check picks up on that.

Silly me. Of course -- R code does not see the preprocessor.

You could move up one level then and ... do it via configure, ie have
'hidden' files osx-init.c, lnx-init.c, win-init.c and copy in the one you
need on a given platform.
 
| But I just found that using string literals in .Call() works just
| fine. Hopefully
| this will still be allowed in the long run:
| 
| .Call("c_non_existent_function_on_this_platform", ...)

So you are adjusting the literals on the fly at compilation time?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org



[Rd] Platform dependent native routine registration
Dirk Eddelbuettel