cmake complains unsuitable version of gl2ps and libharu. cmake says vtk needs gl2ps 1.4.1 but found 1.4.0, and vtk needs libhairu 2.4.0 but found 2.3.0 . However, according to http://geuz.org/gl2ps/ and http://libharu.org/, the latest release of gl2ps is 1.4.0, and the latest release of libharu is 2.3.0.
Our imports have patches applied that VTK needs that have not been accepted/released by upstream yet.
Some Linux distros have pulled these patches into their main packages (and likely patched VTK to accept their version numbers).
There’s a small bit of a rub with this, when combined with the option VTK_USE_EXTERNAL=ON. For users like myself who are compiling vtk from scratch, along with the dependencies from scratch, there’s no way to reconcile the libharu, and likely the other package. Admittedly, I know this is a small subset of users, but is there a possibility to get the patches that are applied to the libharu source, so that I can bring the external dep. from the git release 2.3.0 RC2 up to date? As far as I can tell Debian is still rocking 2.3.0, or at least that’s what apt-cache shows. Same for glps.
That’s because any upstream build you have doesn’t have the patches that provide the API we need. AFAIK, both upstreams have been pretty dormant, so 2.3.0 is probably the latest release anyways. The version is at 2.4.0 in the hope that such a release would have the API we need.
I had noticed that they hadn’t had any commits in quite a long time. With that being the case would you be open to adding an option that effectively overrides the other option for these two packages? Even if it’s undocumented? Something that would effectively allow VTK_USE_EXTERNAL=TRUE while still building libharu and gl2ps internally. I think I can probably set the VTK_USE_$MODULE variables to true/false individually, but that’s a bit of boilerplate I’d rather avoid if I could. Or is it the case that it’s all or nothing in a sense? Do some of the targets in libharu depend on targets in the other directories?
Already exists . Try
VTK_USE_EXTERNAL just sets the default for all of these variables, but they’re individually controllable.
Thanks! I thought I’d grep’d hard enough, :).
The documentation for every flag that affects the build (that isn’t defined and documented in CMake for every CMake project) is in this file. Sometimes new flags sneak in without that being updated, but I try to keep it up-to-date.