v2.0.0 installation fails on macOS about nloptr HOT 10 CLOSED

Thanks for reporting that. Might it be possible that you have a file ~/.Rprofile or a file ~/.Renviron? If you have such a file or files, can you copy their content please?

from nloptr.

Also, it seems you already have nlopt as a system build but of version < 2.7.0. This triggers a cmake build of v2.7.1 and I suspect with all your includes and linking libraries that the compiler might have to choose between both versions and might be a bit lost. If that were to be the case, we should definitely improve upon this situation. In the meantime, I think that if you either upgrade or delete your older version of nlopt, then you should be able to install nloptr successfully.
Alternatively, it might be an issue with the files I mentioned above.

from nloptr.

Thanks for the help!

Thanks for reporting that. Might it be possible that you have a file ~/.Rprofile or a file ~/.Renviron? If you have such a file or files, can you copy their content please?

I checked and I don't see anything that could interfere with the installation. The problem also occurred when running the installation through Rscript --vanilla.

However, removing my previous nlopt installation did the trick! So it seems that there was indeed some confusion between the different versions.

from nloptr.

We might need to dig into this. @eddelbuettel: is the current strategy in configure.ac supposed to avoid this or is there something we missed?

from nloptr.

We made a decision to fail when the version is too low:

We then still force a build. Turns out that those can turn sour. Maybe that can be improved by reordering -I and -L flags to point to 'our' rather than system nlopt. I don't know -- you are the one who thinks we should always build :)

from nloptr.

Actually, I think the issue comes from here:

from nloptr.

Something like that should do the trick:

## But: Can we use pkg-config?
AC_PATH_PROG(have_pkg_config, pkg-config, no)
## If yes, also check for whether pkg-config knows nlopt
if test x"${have_pkg_config}" != x"no"; then
    AC_MSG_CHECKING([if pkg-config knows NLopt])
    if pkg-config --exists nlopt; then
        AC_MSG_RESULT([yes])
        ## Since nlopt has been found, test for minimal version requirement
        AC_MSG_CHECKING([for pkg-config checking NLopt version])
        if pkg-config --atleast-version=2.7.0 nlopt; then
            AC_MSG_RESULT([>= 2.7.0])
            nlopt_include=$(pkg-config --cflags nlopt)
            nlopt_libs=$(pkg-config --libs nlopt)
            AC_SUBST([NLOPT_INCLUDE], "${nlopt_include}")
            AC_SUBST([NLOPT_LIBS],    "${nlopt_libs}")
            need_to_build="no"
        else
            AC_MSG_RESULT([insufficient: NLopt 2.7.0 or later is preferred.])
        fi
    else
        AC_MSG_RESULT([no])
        have_pkg_config="no"
    fi
fi

from nloptr.

(Next time, could you make it easier and show a diff?)

Is the change you are proposing the inner else? Whichmessages but does not error, so inexperienced users may again be lost in front of too much output if it fails later?

PS And I missed that you were posting two tickets at once. Yes -- the propagation of what was found may be related, that is a good catch as we didn't really consider that case.

PPS Yep, agree. Combining tests for 'does it exist and is it new enough' should help!

from nloptr.

We might also remove the setting of have_pkg_config="no" in the else part of the outer if statement since this variable is then not used anymore.
Yes, I'll show a diff next time, sorry.

from nloptr.

Agreed on the have_pkg_config="no", that was just to hop into the next block and all that did not account for crossover effects.

from nloptr.