mxml 4 breaks existing PKG_CHECK_MODULES([MXML], [mxml])

[ejurgensen]

With mxml 4, it looks like mxml.pc became mxml4.pc. That means that any package that depends on mxml and uses PKG_CHECK_MODULES([MXML], [mxml]) in it's configure.ac can no longer find mxml. That doesn't seem ideal?

Here is an example of a broken workflow: https://github.com/owntone/owntone-server/actions/runs/8575529809/job/23504708136

[michaelrsweet]

This was done on purpose to allow Mini-XML 3.x and 4.x to co-exist. The 4.x API is no longer source or binary compatible so I don't want to break existing builds.

[ejurgensen]

But what is package that depends on mxml supposed to do? Switch to PKG_CHECK_MODULES([MXML], [mxml4])? - but then it will break again once mxml 5 is released?

[ejurgensen]

Adding to the above, while I haven't looked into source incompabilities, I assume that a lot of the interfaces work the same as in version 3? So it would be nice if packages that only used them could continue with PKG_CHECK_MODULES([MXML], [mxml]).

If I switch to PKG_CHECK_MODULES([MXML], [mxml4]), then the Debian and Ubuntu builds will fail because they still have version 3. So then I would to do something like first check for mxml4 and if that fails look for mxml in configure.ac. That won't be pretty.

Other libraries (especially ffmpeg!) also have incompabilities between versions, but they don't change pkg-config name. Instead, developers can just check the version number and for instance use macros to use the library calls for that version.

[michaelrsweet]

Yes, check against mxml4 for Mini-XML 4.x.

WRT when a theoretical 5.x is released, I have no plans for that any time in the foreseeable future. For history:

• Mini-XML 1.0 was released in June 2003 (static library only)
• Mini-XML 2.0 was released in June 2004 (source/binary incompatible with 1.x, DSO version 1)
• Mini-XML 3.0 was released in March 2019 (source incompatible, binary compatible with 2.x, DSO version 1)
• Mini-XML 4.0 was released in March 2024 (source and binary incompatible with 3.x, DSO version 2)

2.x and 3.x shared the same underlying node structure (so were binary compatible) but 3.0 made the mxml_node_t structure private which broke source compatibility. There were 6 1.x releases, 15 2.x releases, and 4 3.x releases over a period of 21 years. The changes in 4.0 were designed to future-proof (as much as possible) the API so that changes can be added without breaking source or binary compatibility for a long time...

[michaelrsweet]

Adding to the above, while I haven't looked into source incompabilities, I assume that a lot of the interfaces work the same as in version 3?

No, as the documentation for 4.x says, pretty much everything has changed.

So it would be nice if packages that only used them could continue with PKG_CHECK_MODULES([MXML], [mxml]).

Like I said, the packaging of 4.x is setup to install separately from 3.x so that they can coexist side-by-side.

If I switch to PKG_CHECK_MODULES([MXML], [mxml4]), then the Debian and Ubuntu builds will fail because they still have version 3. So then I would to do something like first check for mxml4 and if that fails look for mxml in configure.ac. That won't be pretty.

Doing new versions of libraries is never pretty which is why I've waited so long on implementing these changes.

Other libraries (especially ffmpeg!) also have incompatibilities between versions, but they don't change pkg-config name. Instead, developers can just check the version number and for instance use macros to use the library calls for that version.

And if the changes were small enough I would have kept the same DSO version and pkg-config name. But they weren't so I didn't...

(Keep in mind that Mini-XML is only one of the many libraries and projects I maintain/develop - the CUPS library has kept the same DSO version/pkg-config name for 26 years, and it is only with CUPS 3.0 that we'll be seeing a new pkg-config name and DSO version, again to allow CUPS 1/2.x and 3.x coexistence...)

[ejurgensen]

Thanks for the explanation, I wasn't aware the changes were that extensive. In that case perhaps a new name like "mxml-ng", "microxml" or something would have been good. I'm still not convinced having version numbers in package names is a good idea. I have a libcurl4 on my system which is actually version 7.xx, and a libgnutls28 which is version 3.xx.

Also, the people maintaining distribution packages of mxml are likely to just bump the version, which I suppose will make it difficult to have both versions installed at the same time, which I understand was you aim. For instance, I still haven't been able to get the CI workflow I linked above to work again, because I can't figure out how to make Homebrew install mxml 3.