R package: Supporting non-standard libomp locations during installation from source #7759
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request adds CPPFLAGS and LDFLAGS to the testing for OpenMP during the R installation from a source package and should fix #7757.
The real change is in
R-package/configure.ac
; most changes inR-package/configure
are because I have a more recent version ofautoconf
than the one used for the previous version of the file.These changes work when applied against the xgboost package on CRAN. I haven't fully understood how to generate the source package for R in the full xgboost source code tree, though; there's a top-level Makefile with a target
Rpack
copying files into a subdirectoryxgboost
. The contents of that directory look like an R package, but no tar.gz or similar is generated.When trying to do an
R CMD INSTALL .
from inside the directory created withmake Rpack
, the compilation fails with C++ build errors foramalgamation/xgboost-all0.cc
. However, the compilation also fails without my changes inmaster
. Thus, I believe it's unrelated to the modification proposed in this pull request - but I have no working knowledge of C++, unfortunately. And maybe it's not the right way to get the R source package anyway. Thecmake
build of the R package appears to work fine, but as far as I understand that won't be affected by the changes in this PR anyway.