Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make libxslt version info available as a first-class member of VersionInfo #1974

Closed
flavorjones opened this issue Jan 27, 2020 · 1 comment
Closed
Milestone

Comments

@flavorjones
Copy link
Member

See #1482 for details around removing the path to libxslt, which is the only piece of metadata that tells us what version of libxslt is being used.

I'd like to see something similar for libxslt as we have for libxml2:

  • track the version used at compile time
  • know the version loaded at runtime
  • emit both versions as part of VersionInfo

This might result in a breaking change to the structure of VersionInfo where libxslt_patches is moved to under its own key and renamed, so the output would be something like:

  nokogiri: 1.10.7
  ruby:
    ...
  libxml:
      binding: extension
      source: packaged
      patches:
      - 0001-Revert-Do-not-URI-escape-in-server-side-includes.patch
      - 0002-Remove-script-macro-support.patch
      - 0003-Update-entities-to-remove-handling-of-ssi.patch
      compiled: 2.9.10
      loaded: 2.9.10
  libxslt:
      binding: extension
      source: packaged
      patches: []
      compiled: 1.1.34
      loaded: 1.1.34
@flavorjones flavorjones added this to the v1.11.0 milestone Jan 27, 2020
@flavorjones
Copy link
Member Author

flavorjones commented Feb 1, 2020

See #1859 for the PR that removed the libxslt paths

flavorjones added a commit that referenced this issue Feb 2, 2020
flavorjones added a commit that referenced this issue Feb 2, 2020
- Renamed constant LIBXML_VERSION to LIBXML_COMPILED_VERSION.
- Renamed constant LIBXML_PARSER_VERSION to LIBXML_LOADED_VERSION.
- Renamed `VersionInfo#loaded_parser_version` to `#loaded_libxml_version` and changed the return type from String to Gem::Version.
- Renamed `VersionInfo#compiled_parser_version` to `#compiled_libxml_version` and changed the return type from String to Gem::Version.
- `Nokogiri.uses_libxml?` now accepts an optional requirement string which is interpreted as a Gem::Requirement and tested against the loaded libxml2 version. This greatly simplifies much of the version-dependent branching logic in both the implementation and the tests.
- use `uses_libxml?` with appropriate version requirements instead of the ad-hoc comparisons used everywhere

related to #1974
flavorjones added a commit that referenced this issue Feb 2, 2020
flavorjones added a commit that referenced this issue Feb 2, 2020
- Renamed constant LIBXML_VERSION to LIBXML_COMPILED_VERSION.
- Renamed constant LIBXML_PARSER_VERSION to LIBXML_LOADED_VERSION.
- Renamed `VersionInfo#loaded_parser_version` to `#loaded_libxml_version` and changed the return type from String to Gem::Version.
- Renamed `VersionInfo#compiled_parser_version` to `#compiled_libxml_version` and changed the return type from String to Gem::Version.
- `Nokogiri.uses_libxml?` now accepts an optional requirement string which is interpreted as a Gem::Requirement and tested against the loaded libxml2 version. This greatly simplifies much of the version-dependent branching logic in both the implementation and the tests.
- use `uses_libxml?` with appropriate version requirements instead of the ad-hoc comparisons used everywhere

related to #1974
flavorjones added a commit that referenced this issue Feb 2, 2020
flavorjones added a commit that referenced this issue Feb 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant