VRT: advertize expression dialects in 'ExpressionDialects' driver metadata item

[rouault]

This will make autotest simpler, as well as for end users / third party code that needs to determine the capabilities of the VRT driver

CC @dbaston

[sgillies]

Different expression dialects? I feel like this may dilute the strength of a great feature. That's something we do too often in this project, in my opinion. Can we pick one expression language? Which is the best?

[rouault]

Which is the best?

not easy to declare a clear winner. Cf discussions in #11209
exprtk is probably the most powerful one, allowing loops etc, but it comes with a rather heavy object size, adding 8 MB to the libgdal binary (so adding half the size of a typical build), cf comment #11209 (comment)
We're going to suggest to packagers to add the muparser dependency (/lib/x86_64-linux-gnu/libmuparser.so.2.2.6 on my system is 375 kB large) for standard builds, tagged as a recommended dependency in our CMake scripts, which the VRT driver considers to be the default one if the dialect isn't specified.

[coveralls]

Changes unknown
when pulling b9dfa11 on rouault:ExpressionDialects
into ** on OSGeo:master**.

[dbaston]

@sgillies The initial motivation for this feature was not to have most users writing their own VRT files, but rather to have gdal_calc support writing to VRT. Since gdal_calc expressions can involve numpy, VRT expressions would need to support Python. But Python is disabled-by-default in VRT and plenty of users want to run GDAL without Python, which creates a need for a second expression dialect that is smaller, causes minimal security concerns, and can be enabled-by-default. We've selected muparser for that purpose.

We're also supporting exprtk, which is in between the capabilities of muparser and Python. As a feature that is not enabled by default, I don't see it finding a wide audience. On the other hand, supporting it doesn't require a lot of code. Is GDAL improved by removing support for it? I don't have a strong opinion. But removing it would not remove the concept of dialects.

[rouault]

@dbaston I believe @hobu mentionned it only wants muparser or python to be expression dialects. So should we remove completely exprtk support, or not advertize it ?

[dbaston]

It's worth continuing the discussion, but I think the changes proposed here are positive either way.

[rouault]

but I think the changes proposed here are positive either way.

yes, true. At worse the #ifdef GDAL_VRT_ENABLE_EXPRTK won't be triggered, and we'll clean that up

Merging