Comments (13)
Thanks for sharing the issue.
As a side note, the system requirement is cmake
but the version >= 2.7.0
refers to nlopt
. I will make that clearer in a future release.
Also, I might switch to using one core only to compile nlopt
, avoiding at all the -j
flag. After all, it is pretty quick to compile on the fly wrt other external libraries.
Or I might put a requirement on the version number of cmake
that is required. The 3.10
is far behind the newest 3.22
.
from nloptr.
@eddelbuettel, please - it's counterproductive to talk down to users running on older Linux distros (still in LTS), especially since there are lots of users in such a situation. Such comments risk preventing others from reporting similar problems they experience in the future. I personally have the skill and the options run with modern versions, and I do, but that's not the issue, or why I reported this here. I reported this here because I know there are 1,000's of users out there on these distros, and they might be struggling at this very moment, and if they don't have the experience or the skills, these error messages can be major blockers. It's also clear that the maintainer is not on this platform, because then they'd noticed. So, I am just trying to help all sides here. By reporting this problem here, others might pitch in, e.g. by identifying a better lower bound of CMake than 2.7.0 that @astamm can specify in the DESCRIPTION. That alone, might spare lots of hours across the world. I could have chosen not to spend 15 minutes troubleshooting and writing this up to share my experience here.
from nloptr.
I am very grateful indeed @HenrikBengtsson. I am indeed more of a Mac user and I admit I had not thought of people using too old versions of cmake
. I think the option of putting a version number requirement on cmake
is safer because, who knows, if someone uses a version older than yours, there might be other issues he could face. On the other hand, I could lower down this requirement at least at the version of cmake
you currently use if I switch to always using one core. Hmm, I'll think about the options and implement one in the next release. And I will definitely make the SystemRequirements
field clearer. Thanks again for taking the time, really.
from nloptr.
Install libnlopt directly (in a current enough version) and cmake
is no longer needed.
from nloptr.
Install libnlopt directly (in a current enough version) and
cmake
is no longer needed.
Thanks. Yes, I understood that as a workaround, but wanted to share that the everything-from-source version is not working.
from nloptr.
Yes, @astamm is learning step by step that simply saying 'hey my package requires cmake
' does not solve all problems all the time....
Also, "everything from source" is working to the satisfaction of CRAN, so (in shorthand notation) "is working". Your choice of combining a four-year old OS release with a new / current CRAN package simply puts up new challenges for you that we do not promise to have cleared. (I understand where you come from with ancient HPC setups etc; @astamm as a CNRS employee is probably sympathetic but "we all" just have to draw some lines somewhere.)
from nloptr.
Thanks, @astamm. All your alternatives sounds good to me.
from nloptr.
@astamm To be perfectly honest one thing that would really help is to not rely on cmake
in the first place. That would have prevented #99 yesterday as well. As discussed, maybe use it create a Makefile
(or set of Makefiles) and ship those. I am sure @HenrikBengtsson will be glad to be of assistance on his platform to test that setup. What we all have going for us here is that a) NLopt does not demand much and b) neither does R. But everthing can (and will) get in the way because invariably you will get another user who thinks you should also support Ubuntu 16.04, or CentOS 5.*, or ...
from nloptr.
Always happy with honesty :-) That could be a way too as we discussed indeed. I kind of like the idea of cmake
which stands for cross-platform make
and is supposed to make cross-platform availability easier. And I think that people running on too old versions of cmake
(where too old is wrt the use we are making of it) should simply be informed that if they want to be able to use the nloptr
package then they either need a recent enough version of cmake
(>= 3.sthg
) or a recent enough system build of nlopt
(>=2.7.0
). I understand why some people sometimes need to stay on older versions of things but I'd rather encourage to install at least some recent enough versions. Of course, that means we might lose some current nloptr
users. But they might come back later as well.
from nloptr.
No need to explain cmake
to me, we use it at my day job, and I see it in many other projects. What I have been trying (and failing) to get across is that it is not common on R build systems. Hence your long dialogue with Tomas. Hence #99.
It's complicated. For my $dayjob package I now have to rely on C++17. Which is, quite frankly, awesome for being able to use regexps and file system modules and whatnot but a pain for code builds. We also depend on a much newer cmake
so I try hard to not let the R package at CRAN require using it. It's all about tradeoffs. And customs. And R is a GNU project to autoconf
/ configure
is quite simply the standard so far. But hey you got Prof Ripley to add an entire section on cmake
to the manual so who know in a decade or two you may be the one standing here and smiling
from nloptr.
@HenrikBengtsson I re-read what I wrote. There is not talking down here anywhere. All I continue to say is 'works at CRAN, we offer help here as volunteers'. If you use a non-CRAN platform, the excitement and adventure is all yours. I look forward to many more such reports.
from nloptr.
TL;DR: I think the requirement should be cmake (>= 3.15.0)
.
It looks like cmake gained support for -j ${NCORES}
in version 3.13.0.
However, trying with cmake 3.13.0-3.14.5 gives:
> install.packages("nloptr")
...
[ 96%] Linking CXX static library libnlopt.a
[100%] Built target nlopt
CMake Error: The source directory "/home/hb/repositories/other/nloptr/src/nlopt" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
cp: cannot stat 'nlopt/include/*': No such file or directory
configure: creating ./config.status
config.status: creating src/Makevars
...
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (nloptr)
So, still an error, but install.packages()
doesn't realize it.
Using cmake 3.15.0, or newer, works!
(*) Building from source (obviously) requires nlopt.h
on the system, which on Ubuntu is provided by sudo apt install libnlopt-dev
.
from nloptr.
Thanks @HenrikBengtsson. I will add this to the SystemRequirements
field.
from nloptr.
Related Issues (20)
- Compiling error when installing due to abs ambiguous call HOT 4
- set_vector_storage LBFGS HOT 2
- Error installing `nloptr` from source on CentOS cluster HOT 16
- Python vs R Speed Differences HOT 2
- How to address CRAN request to remove C++11 when it is not needed? HOT 5
- The old implementation of COBYLA is buggy and challenging to maintain. Switch to the PRIMA implementation? HOT 2
- Equality constraint with COBYLA HOT 5
- Compilation fails R4.3.0 HOT 20
- Tests for directL fail HOT 3
- Make tinytest unit test files self-sufficient HOT 4
- Three test files assume `options(digits=7)` but do not set it HOT 3
- R installation error: cannot find libnlopt.so.0 HOT 15
- Add functions for setting parameter bounds HOT 2
- Update cmake installation instructions on Mac with brew HOT 1
- Inequality direction in wrapper functions HOT 5
- Output for two auglag() examples in package reference manual is not reproducible HOT 3
- Annotations in reference manual example code are incorrect HOT 3
- push a new version to CRAN? HOT 11
- Slow Convergence Times For Local Gradient Based Algos HOT 8
- Modification of test-C-API.cpp HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nloptr.