Tests fail with out IDN about trurl

[bagder]

Ah yes. We need to poll the used libcurl version for IDN support (using curl_version_info) and probably output that info somehow so that we can figure that out and then avoid those tests...

[jacobmealey]

Would it make sense to just print the entirety of feature_names in the output of trurl --version? and then of course update tests.json to specify a specific feature and test.py to skip these features.

[krishean]

I ran into this as well when compiling libcurl as a static library on an ubuntu install that did not have libidn2-dev installed. I just installed the necessary package to get around it, but having a way to see what feature flags are enabled and be able to adjust what tests are run accordingly could be nice

[krishean]

Printing the feature names on a separate line like curl has could be parsed into an array or list in test.py and compared against an array in the json of features required by a given test

[jacobmealey]

excellent, that's what I was thinking as well.
The only worry I have is that there are many features in curl that would be listed that aren't even touched in trurl. we wouldn't want to give a user the idea that trurl has some features (for example AsynchDNS) that it makes no use of, which seems like it would get confusing.

[krishean]

Maybe have a prefix at the beginning of the line such as "libcurl features: " to make sure the user is aware that they are inherited from libcurl, and not necessarily directly related to trurl?

[bagder]

I think we should only show features that are relevant for trurl, which for now only is IDN. Otherwise we will show a very long list of things that are irrelevant.

We could possibly convert some of our libcurl version-dependent things to instead become named features: normalize-ipv6, normalize-ipv4 for example.