search

astamm / riot

riot: R Inputs/Outputs for Tractography
https://astamm.github.io/riot/
Other
4 stars 1 forks source link

Use of configure to use existing VTK libs #2

Closed astamm closed 2 years ago

astamm commented 2 years ago

It could be nice not to compile VTK from scratch if a suitable system build is found. @eddelbuettel can I please adapt the configure.ac file you kindly contributed to nloptr to fit my needs here?

eddelbuettel commented 2 years ago

Of course you can -- it is open source pure and pure, and similar ones are found in many other CRAN repos of mine and others. I'll help too if you need me.

astamm commented 2 years ago

Thank you. Well, the goal of this package is to provide IO interface to common VTK polygon formats (lists of 3d points belonging to specific lines/polygons with possibly some attributes at each point) which are .vtk and .vtp files mainly. For that purpose, I need to link with a few libs in VTK, but not all: specifically, -lvtkCommonCore -lvtkCommonDataModel -lvtkCommonExecutionModel -lvtkCommonMath -lvtkCommonMisc -lvtkCommonSystem -lvtkCommonTransforms -lvtkdoubleconversion -lvtkexpat -lvtkIOCore -lvtkIOLegacy -lvtkIOXML -lvtkIOXMLParser -lvtkkissfft -lvtklz4 -lvtklzma -lvtkpugixml -lvtksys -lvtkzlib.

These libs are the basic ones that every build of VTK will include. So I was thinking that it could save time if we could detect if they are already built via pkg-config because building VTK from source is quite time-consuming.

I have a working version (not yet pushed here) for Linux and macOS, which needs to be cleaned up a bit.

Then of course, remains the issue on Windows, as, differently from nlopt, VTK is neither on rwinlib nor on the Rtools42 toolchain.

Finally, I am also wondering whether I should rather provide a dedicated package RcppVTK (or other naming) for interfacing VTK with R. But this seems more work w.r.t. my needs although it could benefit other people more than my current strategy.

eddelbuettel commented 2 years ago

(Quick "btw" I mentioned to you before: One can/could of course also do what I do in configure.ac via cmake; but there is as you are now learning via baptism by fire a little bit of a cultural/circular problem that the R universe simply does not always have cmake, or has ancient versions, or .... Which is the one problem autoconf solves well (the result is just a (large but still) shell script. And the 'cost' of 'but not on Windows' does not matter. I have one or two colleages reasonably good at cmake (as we do need it on other platforms for non-R builds) I could lean on but because of the above ... I am not sure.)

pkg-config is good on Linux/macOS/Unix/..., and a (by now) widespread standard supported by all libraries. I wrote the first such configure.ac for RQuantLib about 20 years ago (with help from Kurt Hornik learning these ropes) and it at the time had a local quantlib-config. Same with GNU GSL. By now everybody uses pkg-config so it is good. As I mentioned. Jeroen drives that from shell too. Your call. No help whatsoever on Windows which is its own world.

CRAN does allow 'not on Windows' packages if you reason why. Library does build / exist is good enough.

I think I once knew of a Rcpp-based VTK interface package. I would need to look.

astamm commented 2 years ago

Thank you for all these very helpful discussions. I am thinking of a solution for Windows. Indeed, while they do not have VTK in rtools toolchain (Jeroen did tell me how to add it but also warned me that it might not be straightforward, and since Tomas' toolchain should supersede his at some point, I am not sure at the time spent/benefits compromise here), they do have cmake in the toolchain. So I could use the toolchain version of cmake to always build from included sources on windows platforms.

eddelbuettel commented 2 years ago

It is 2022. You could also tell Windows users to live with WSL2 "for now". Nobody is forcing you to build Rome in a single day.

I did have luck in the past 'going out there' with repos lacking Windows parts for builds and ... lo and behold often enough someone comes by with more knowledge of, and interest or need in, Windows than I now have. A Windows build may build organically like that. Or it may not as VTK is indeed on the larger side.

astamm commented 2 years ago

@eddelbuettel Do you have an os with a system build of vtk 9.0.1 on your https://eddelbuettel.github.io/r-ci/ platform if I wanted to test a strategy to bypass cmake installation of VTK if a system build is detected? From what I can see, on ubuntu 20.04 the dev lib available from apt-get seems stuck at VTK 7.1.1.

eddelbuettel commented 2 years ago

r-ci is 'mostly just for me' (or 'effectively calibrated to what I need') and as it works well (and is used by a few others but I don't have full usage stats). I use Ubuntu 20.04 there as it is common and because I have it wrapped up with BSPM to serve me binaries pre-made.

Which I sometimes use to add binaries into additional PPAs (or just "my PPAs") to have them. Case in point is QuantLib (where many of these build optimizations started as the library can take 90 mins or longer to build and the package can take 10+ min for one run which is why I added ccache to Docker to 'fill the cache' when R checks 'can I install?' (or maybe 'can I build') and then loads from the cache when it actually run tests).

So a high-end longer-term solution would be for you to provide Ubuntu binarys for VTK (or, hey, just use them via the PPA hook in r-ci !!) to make your setup smarter. Not a VTK user so no idea if these exist. I do know kitware has an apt-getable repo for cmake (as $work recently imposed version 3.21 exactly because of an issue with an upstream library to us, don't get me started ....)