[R-pkg-devel] C++ library USING_R

[Joseph Park]

Apologies for the mis-directed reply, and, imprecise syntax/context re 
environment variable.

Just to close the loop, it seems that using a -D macro assignment inside 
the make command (macro?) is interpreted as a make option:

$(LIBEDM):
     @(cd $(CPPEDM_SRC_PATH) && $(MAKE) clean && $(MAKE) \
     CXX="$(CXX11) $(CXX11STD)" CXXFLAGS="$(CXX11FLAGS) $(CXX11PICFLAGS)" \
     AR="$(AR)" RANLIB="$(RANLIB)" -DUSING_R=1)

...

    make[1]: Entering directory 
'/tmp/RtmpxVmJkT/Rbuild1553f22c7484d/rEDM/src/cppEDM/src'
    rm -f API.o CCM.o Common.o DateTime.o EDM.o EDM_Formatting.o 
EDM_Neighbors.o Eval.o Multiview.o Parameter.o Simplex.o SMap.o libEDM.a
    make[1]: Leaving directory 
'/tmp/RtmpxVmJkT/Rbuild1553f22c7484d/rEDM/src/cppEDM/src'
    make: invalid option -- 'D'

Hmm... since I use an R-specific makefile inside the C++ library 
directory anyway, adding -DUSING_R there seems like a decent solution.

Thanks a-million for the support & guidance to get me to the obvious 
solution!

J Park

On 10/15/20 8:17 AM, Dirk Eddelbuettel wrote:
> *Please* direct this back to the list if you have another follow-up. Private
> email is not efficient / has no second or third or ... set of eyes.
>
> On 15 October 2020 at 07:53, Joseph Park wrote:
> | Thanks for the clarification.
> |
> | One last caveat: the C++ code already has a hook presuming #define
> | USING_R. Does it seem reasonable/safe to use that as the variable passed
> | to the C++ library build instead of say R_BUILD?
>
> Hm, here I do not understand how you think that a _constant_ declaration can
> help you detect a _variable_ situation ("are we / are we not compiled for R").
>
> If you mainly wonder about the name of the variable: your code. You can do
> what you want. Nobody cares. No "defaults".
>   
> | Or, does defining USING_R as an environment variable (-D) have potential
>
> -D is not an envinronment variable.
>
> -D is a #define passed tot he compiler.
>
> | unintended consequences since the R headers already have defined it?  I
> | would think it's OK since the library/build is "independent" from R.
>
> A build triggered from src/Makevars is NOT independent of R.
>   
> | As a disciple of PEP20, I suppose (re)defining USING_R for specific
> | purposes is a bad idea...
>
> I have no idea what PEP20 is. I helped you from an R list. Do not assume I
> know (Python?) lingo.
>
> Dirk
>   
> | J Park
> |
> | On 10/15/20 7:32 AM, Dirk Eddelbuettel wrote:
> | > (Replies on-list preferred)
> | >
> | > On 15 October 2020 at 07:08, Joseph Park wrote:
> | > | Thank you.  It always stings a bit to miss the obvious solution as you
> | > | have suggested. :(
> | >
> | > No worries :)  R builds are "special" enough to warrant an iteration or two to
> | > get familiar with the pecularities.
> | >
> | > | Yes, the C++ library is built during the R package install.
> | > |
> | > | We have in Makevars:
> | > |
> | > | all : $(SHLIB)
> | > |
> | > | $(SHLIB): $(LIBEDM)
> | > |
> | > | $(LIBEDM):
> | > |      @(cd $(CPPEDM_SRC_PATH) && $(MAKE) clean && $(MAKE) \
> | > |      CXX="$(CXX11) $(CXX11STD)" CXXFLAGS="$(CXX11FLAGS) $(CXX11PICFLAGS)" \
> | > |      AR="$(AR)" RANLIB="$(RANLIB)")
> | > |
> | > | The obvious solution is to add an environment variable in the LIBEDM
> | > | build command, ala:
> | > |
> | > | R_BUILD=1
> | > |
> | > | Then the C++ code can use #ifdef R_BUILD ...
> | > |
> | > | Is this tenable, or, is there another preferred approach?
> | >
> | > No, that is what I would do as a -D.... option to the compiler call ie
> | > directly add -DR_BUILD=1 here
> | >
> | > $(LIBEDM):
> | >        @(cd $(CPPEDM_SRC_PATH) && $(MAKE) clean && $(MAKE) \
> | >        CXX="$(CXX11) $(CXX11STD)" CXXFLAGS="$(CXX11FLAGS) $(CXX11PICFLAGS)" -DR_BUILD=1 \
> | >        AR="$(AR)" RANLIB="$(RANLIB)")
> | >
> | > or expand CXX11FLAGS with a += but then CRAN does not like us to use GNU Make
> | > extensions so the above may be easiest.
> | >
> | > Dirk
> | >
> | > | Thanks!
> | > |
> | > | J Park
> | > |
> | > | On 10/14/20 9:40 PM, Dirk Eddelbuettel wrote:
> | > | > On 14 October 2020 at 15:56, Joseph Park wrote:
> | > | > | Dear R-devel,
> | > | > |
> | > | > | The Writing R Extensions manual states:
> | > | > |
> | > | > | 6.14 Platform and version information
> | > | > | The header files define USING_R, which can be used to test if the code
> | > | > | is indeed being used with R.
> | > | > |
> | > | > | I suppose this only applies to building R itself?  Or, perhaps when Rcpp
> | > | > | is used for the interface, or if one includes R headers explicitly.
> | > | > |
> | > | > | I have a C++ library that is built with no R-dependencies, then wrapped
> | > | > | with an Rcpp interface. This same library is wrapped with pybind11 in
> | > | > | the Python world, and directly used in C++ applications.
> | > | > |
> | > | > | How can the C++ library code "know" that it's R building the library? Is
> | > | > | there a platform-independent environment variable or macro?
> | > | >
> | > | > So if I have this right you have
> | > | >
> | > | >    - a library LIB using only standard C++ components
> | > | >
> | > | >    - that you wrapped into a Python package via pybind11, and
> | > | >
> | > | >    - that you want to build for R and 'let it know it used for R'
> | > | >
> | > | > Well I think you would then use a (wrapper) R package R_LIB and could set up
> | > | > a -DR_BUILD in the src/Makevars for R_LIB. This presume that you actually
> | > | > recompile LIB as part of the build; if you were to link with a static or
> | > | > shared build then you could not do this _for lack of a subsequent
> | > | > compilation_ and can only rely on run-time information.
> | > | >
> | > | > Hope this helps, and that I didn't misunderstand the question.
> | > | >
> | > | > Dirk
> | > | >
> | >
> |
>
-- 
Joseph Park <http://jpark.us/>, PhD, PE
U.S. Department of Interior <https://www.doi.gov/>, SFNRC 
<https://www.nps.gov/ever/learn/scienceresearch.htm>
Software Literacy Foundation <http://softwareliteracyfoundation.org/>
UCSD Sugihara Lab <https://deepeco.ucsd.edu/>

	[[alternative HTML version deleted]]