Fails on Linux when it shouldn't

[eddelbuettel]

We have cmake

edd@paul:~/git/ta-lib-r(devel)$ which cmake
/usr/bin/cmake
edd@paul:~/git/ta-lib-r(devel)$ 

yet we see

edd@paul:~/git/ta-lib-r(devel)$ install.r
* installing *source* package found in current working directory ...
* installing *source* package ‘talib’ ...
** this is package ‘talib’ version ‘0.9-1’
** using staged installation

Configure for {talib} v0.9-1

Build-step: Checking for R_HOME [OK]
Build-step: Compiling C-program with R CMD SHLIB [OK]
Build-step: Compiling TA-Lib program with system headers [Failed]
 Build-error:
CMake not found on PATH==========================================================================
Install CMake:
  Linux:
    Debian/Ubuntu: sudo apt-get update && sudo apt-get install -y cmake
    Fedora/RHEL/CentOS: sudo dnf install -y cmake
    Arch: sudo pacman -S --needed cmake
    openSUSE: sudo zypper install -y cmake

  macOS:
    Homebrew: brew install cmake
    MacPorts: sudo port install cmake

Alternatively download the installer: https://cmake.org/download/
After installation, restart the shell or add CMake to PATH
==========================================================================
Submit bug-reports here: https://github.com/serkor1/ta-lib-R

ERROR: configuration failed for package ‘talib’
* removing ‘/usr/local/lib/R/site-library/talib’
Warning message:
In install.packages(pkgs = f, lib = lib, repos = if (isMatchingFile(f)) NULL else repos) :
  installation of package ‘.’ had non-zero exit status
edd@paul:~/git/ta-lib-r(devel)$ 

[eddelbuettel]

It seems that the displayed error is simply wrong, but it should have vendored. When I rely on apt to install ta-lib-dev all is well.

[eddelbuettel]

"My mistake" -- I feell for git clone and did not check for required submodules. Suggesting that maybe

1. You state that more clearly in the README.md, just in case

2. On the following line disentangle the double check into two. I had one of the two, but not the other and my confusion was due to the message being (wrongly) attributed to the former.

ta-lib-R/configure

Line 250 in 477a85b

if command -v cmake >/dev/null 2>&1 && [ -f "$TALIB/CMakeLists.txt" ]; then

You also need to replace cmake with S{CMAKE} and set it as eg here -- there is a hint in Writing R Extensions that "they" in all their wisdom keep it off the ${PATH} on macOS.

[serkor1]

Thank you so much for opening this issue @eddelbuettel - I think it makes sense to remove && [ -f "$TALIB/CMakeLists.txt" ] from the condition altogether. Its very unlikely that it doesn't exist.

If you cloned without --recursive you should have ended here:

   Build-error: src/ta-lib not found. Either make a new clone, or initialize the submodule.
   Clone:		git clone --recursive https://github.com/serkor1/ta-lib-R.git
   Initialize:	git submodule update --init --recursive

So that is another bug in the configure that I need to fix. Again, thank you so much.

[eddelbuettel]

Given that I actually fell into that very hole, I think that test SHOULD ABSOLUTELY exist! So I think the flow is

• check for system
• if fallse prepare for vendor
  • check cmake and git
  • check src/ are present

and that last one is missing.

You have one more bug. A library may be locally installed and should be used, but you may end up not finding it! Your test for 'can I compile against ta-lib' has one or two shortcomings I learned along the way doing similar things:

1. You must check for pkgconf first and then use it to infer compiler and linker flags
2. You should build something and run it, test header and library

That latter is point on linking is more of a recommendation but you should definitely try to reflect pkg --cflags ta-lib for the header location.

[serkor1]

Yeah, no you are correct the test should absolutely exist. I actually just opened a PR where I use the test earlier in the branch. As for your second bug - I will play around with it and see how it goes.

[serkor1]

Allow me to close this issue as I believe the immediate CRAN-related issues are fixed in #47, then I will open another issue related to your second bug.

[eddelbuettel]

Yes #47 looks good for the cmake issue. We take it one step at a time.