On 08.12.24 14:07, Will Godfrey wrote:
I've just seen that the latest version of this is quite a major incompatible shift.
The only thing I can think of that would completely resolve these would be to grab a copy of mxml 2.5 (or maybe 3.3.1) and build it into Yoshimi. I'd rather not do that if we don't have to, but has anyone got any ideas?
Obviously, especially parsing XML is a complex topic and it seems better to share the workload for maintenance. A relevant question of course is regarding the nature of the changes. Are they cosmetic? do they change the systematic how one is assumed to work with the library? Is there any known text, video, blog article where the motivation and changes are described by the libraries authors? One option would be to look for other alternatives? What are other projects using for reading and writing XML? Maybe switching to some very widely used, very mainstream library, which hopefully cares more about backwards compatibility and attempts not to break APIs? Other than that, what is always possible is to introduce some kind of abstraction in between. To some degree, we do already use a reader / writer component, but this can be driven some steps further. We could distil a list of those operations we actually need and put our own API in front of these. Of course the implementation would just delegate to the library. If we do that, we could then have two different implementations in-tree and pick the right one (at compile time) for the library version actually available on the user's system. This approach would work most painless if there is a clear trait in the code of the library itself to recognise the presence of the new-style API. E.g. if the new API has a function with a different name or a different signature. Or maybe the library itself provides a marker definition to recognise the presence of the new API. It is then not too difficult to make the compiler itself pick up the right wrapper for the given situation. Of course, we could also do it in the old fashioned way, with macros, conditional compilation and some support of the build system CMake. Anyway, keeping this kind of change encapsulated into our own adapter always helps to keep the changes isolated. -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
