[Rcpp-devel] sourceCpp and #include .hpp ?

Hi Tal,

If you run sourceCpp(..., verbose=TRUE), you'll see that the source code is
copied into a temporary directory, and then the working directory is reset
to that directory. So the header file is no longer discovered there. (not
to mention, you would have to tell sourceCpp where to find those function
definitions that have been included as well... building a package does that
behind the scenes for you)

I think you should stay with recompiling the package, rather than switching
to sourceCpp, when debugging a package.

-Kevin

Hello dear list members,

I'm working the an a package with Rcpp code, and would like to have a cpp
function in one file, and then be able to access it from another.
It appears that using:
#include "file_name.hpp"
Works great while compiling.

However, when debugging the file, I discovered the when I use "sourceCpp"
on the file which has "#include", it is not able to find the other
functions and I get:

fatal error: src/is_functions.hpp: No such file or directory compilation
terminated. make: *** [get_branches_heights.o] Error 1
Error in Rcpp::sourceCpp("src/get_branches_heights.cpp") :
  Error 1 occurred building shared library.


I've tried using:
#include "src/file_name.hpp"
instead, but it didn't help either.

Is there something I'm missing?


Thanks.





----------------Contact
Details:-------------------------------------------------------
Contact me: Tal.Galili at gmail.com |
Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) |
www.r-statistics.com (English)

----------------------------------------------------------------------------------------------

_______________________________________________
Rcpp-devel mailing list
Rcpp-devel at lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20130819/77e23e80/attachment.html>

| If you run sourceCpp(..., verbose=TRUE), you'll see that the source code is
| copied into a temporary directory, and then the working directory is reset to
| that directory. So the header file is no longer discovered there. (not to

Correct.  [ A colleague was just bitten / frustrated by that today. ]

| mention, you would have to tell sourceCpp where to find those function
| definitions that have been included as well... building a package does that
| behind the scenes for you)
| 
| I think you should stay with recompiling the package, rather than switching to
| sourceCpp, when debugging a package.

You can also use a standard -I/some/path/... switch --- but for the reason
Kevin explained so nicely (ie R building in a temp. dir) you cannot just say
"use my local dir" via -I. but have to be explicit: -I/home/tal/some/dirk or,
if you must -IC:/some/win/doze/path.

Longer-term, a package is your friend. And hey, you already have one :)

Dirk

Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com

Thank you Kevin and Dirk,
I was hoping for for an easier fix (such as, having sourceCpp give a
parameter controlling where it was building the thing).
Thank you both for the explanations.

Best,
Tal




----------------Contact
Details:-------------------------------------------------------
Contact me: Tal.Galili at gmail.com |
Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) |
www.r-statistics.com (English)
----------------------------------------------------------------------------------------------

On 19 August 2013 at 11:51, Kevin Ushey wrote:
| If you run sourceCpp(..., verbose=TRUE), you'll see that the source code
is
| copied into a temporary directory, and then the working directory is
reset to
| that directory. So the header file is no longer discovered there. (not to

Correct.  [ A colleague was just bitten / frustrated by that today. ]

| mention, you would have to tell sourceCpp where to find those function
| definitions that have been included as well... building a package does
that
| behind the scenes for you)
|
| I think you should stay with recompiling the package, rather than
switching to
| sourceCpp, when debugging a package.

You can also use a standard -I/some/path/... switch --- but for the reason
Kevin explained so nicely (ie R building in a temp. dir) you cannot just
say
"use my local dir" via -I. but have to be explicit: -I/home/tal/some/dirk
or,
if you must -IC:/some/win/doze/path.

Longer-term, a package is your friend. And hey, you already have one :)

Dirk

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20130820/4796869f/attachment.html>

I've run into the same issue and have been using the Rcpp's plugin framework to work around it.

My R file defines a local_include plugin as follows:

registerPlugin("local_include", 
                function() {
                    list(env = list(PKG_CXXFLAGS=paste0("-I",path.expand("~/Desktop/project/include"))))
                }
              )

and the cpp file uses that plugin with:

// [[Rcpp::plugins(local_include)]]

This also works well if you need to link to some additional library or anything else compiler flag related.

-Colin

Thank you Kevin and Dirk,
I was hoping for for an easier fix (such as, having sourceCpp give a parameter controlling where it was building the thing).
Thank you both for the explanations.

Best,
Tal




----------------Contact Details:-------------------------------------------------------
Contact me: Tal.Galili at gmail.com |  
Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) | www.r-statistics.com (English)
----------------------------------------------------------------------------------------------



On Tue, Aug 20, 2013 at 2:54 AM, Dirk Eddelbuettel <edd at debian.org> wrote:

On 19 August 2013 at 11:51, Kevin Ushey wrote:
| If you run sourceCpp(..., verbose=TRUE), you'll see that the source code is
| copied into a temporary directory, and then the working directory is reset to
| that directory. So the header file is no longer discovered there. (not to

Correct.  [ A colleague was just bitten / frustrated by that today. ]

| mention, you would have to tell sourceCpp where to find those function
| definitions that have been included as well... building a package does that
| behind the scenes for you)
|
| I think you should stay with recompiling the package, rather than switching to
| sourceCpp, when debugging a package.

You can also use a standard -I/some/path/... switch --- but for the reason
Kevin explained so nicely (ie R building in a temp. dir) you cannot just say
"use my local dir" via -I. but have to be explicit: -I/home/tal/some/dirk or,
if you must -IC:/some/win/doze/path.

Longer-term, a package is your friend. And hey, you already have one :)

Dirk

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

_______________________________________________
Rcpp-devel mailing list
Rcpp-devel at lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20130819/cdd71fc8/attachment.html>

| I've run into the same issue and have been using the Rcpp's plugin framework to
| work around it.
| 
| My R file defines a local_include plugin as follows:
| 
| registerPlugin("local_include", 
|                 function() {
|                     list(env = list(PKG_CXXFLAGS=paste0("-I",path.expand("~/
| Desktop/project/include"))))
|                 }
|               )
| 
| and the cpp file uses that plugin with:
| 
| // [[Rcpp::plugins(local_include)]]
| 
| This also works well if you need to link to some additional library or anything
| else compiler flag related.

Well done. That is the correct approach, using the hooks the build system
provides via the inline package as well as Rcpp Attributes.

Dirk
 
| -Colin
|

| 
| 
|     Thank you Kevin and Dirk,
|     I was hoping for for an easier fix (such as, having sourceCpp give a
|     parameter controlling where it was building the thing).
|     Thank you both for the explanations.
| 
|     Best,
|     Tal
| 
| 
| 
| 
|     ----------------Contact
|     Details:-------------------------------------------------------
|     Contact me: Tal.Galili at gmail.com | 
|     Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) |
|     www.r-statistics.com (English)
|     ----------------------------------------------------------------------------------------------
| 
| 
|

| 
|

|         | If you run sourceCpp(..., verbose=TRUE), you'll see that the source
|         code is
|         | copied into a temporary directory, and then the working directory is
|         reset to
|         | that directory. So the header file is no longer discovered there.
|         (not to
| 
|         Correct.  [ A colleague was just bitten / frustrated by that today. ]
| 
|         | mention, you would have to tell sourceCpp where to find those
|         function
|         | definitions that have been included as well... building a package
|         does that
|         | behind the scenes for you)
|         |
|         | I think you should stay with recompiling the package, rather than
|         switching to
|         | sourceCpp, when debugging a package.
| 
|         You can also use a standard -I/some/path/... switch --- but for the
|         reason
|         Kevin explained so nicely (ie R building in a temp. dir) you cannot
|         just say
|         "use my local dir" via -I. but have to be explicit: -I/home/tal/some/
|         dirk or,
|         if you must -IC:/some/win/doze/path.
| 
|         Longer-term, a package is your friend. And hey, you already have one :)
|        
|         Dirk
| 
|         --
|         Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
|    
| 
|     _______________________________________________
|     Rcpp-devel mailing list
|     Rcpp-devel at lists.r-forge.r-project.org
|     https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
| 
| 
| 
| ----------------------------------------------------------------------
| _______________________________________________
| Rcpp-devel mailing list
| Rcpp-devel at lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com