Split wxsvg Into Multiple Packages Built Against Different wxWidgets Versions

[AntumDeluge]

• replaces package wxsvg with wxsvg-wx3.0
• adds package wxsvg-wx3.1
• adds package wxsvg-wx3.2

[AntumDeluge]

Ready for review.

Edit: Is there a way for packages to share patches? I know a remote URL can be used, but the patch isn't hosted anywhere. I tried using a relative path to the original patch. But that didn't work so I copied it into all package directories.

[AntumDeluge]

Could I get a review on this? My software depends on wxWidgets 3.1 & wxSVG. The current wxSVG package is built against wxWidgets 3.0. So I can't build my software. This pull adds two versions of wxSVG built against wx 3.1 & 3.2 respectively. I know devs with write permission are probably busy. I just don't want this to get buried.

[1480c1]

Would there be some way to keep all the version that at least share the same steps (sorta) inside one PKGBUILD and instead use something like a _wx_versions array and loop through that instead? This seems like a lot of duplication

Is there a reason to keep the older versions? Are they incompatible with the later ones?

[AntumDeluge]

Would there be some way to keep all the version that at least share the same steps (sorta) inside one PKGBUILD and instead use something like a _wx_versions array and loop through that instead? This seems like a lot of duplication

Actually, I would like that very much. I just didn't know how to do it. The different wxWidgets packages each have their own PKGBUILD, so I figured I needed to do the same with wxSVG. But I will see if I can figure out how to put them all in one PKGBUILD file.

Is there a reason to keep the older versions? Are they incompatible with the later ones?

I don't know why wx was split into three versions or if there is a reason to keep 3.0 & 3.1. That is probably a question for the maintainers.

[1480c1]

I don't know why wx was split into three versions or if there is a reason to keep 3.0 & 3.1. That is probably a question for the maintainers.

https://github.com/msys2/MINGW-packages/pull/4748

seems we would need to ask @stahta01 about that one, but I'm guessing maybe it's something like something compiled and linked against 3.0 might not necessarily work as intended when doing the same against 3.2 or something

Actually, I would like that very much. I just didn't know how to do it. The different wxWidgets packages each have their own PKGBUILD, so I figured I needed to do the same with wxSVG. But I will see if I can figure out how to put them all in one PKGBUILD file.

All I know about this one is that it's something to do with having separate package_name() functions and using a loop and eval or something, but I don't know exactly how to do so, I've just seen it here and there

[AntumDeluge]

All I know about this one is that it's something to do with having separate package_name() functions and using a loop and eval or something, but I don't know exactly how to do so, I've just seen it here and there

Thanks, that gives me a clue. I'm sure I will be able to figure out the rest. 🙂

[AntumDeluge]

For reference, I was referred to manpage PKGBUILD.5#PACKAGE_SPLITTING for creating multiple packages from a single PKGBUILD.

[AntumDeluge]

Check passes but there is an error in the PKGBUILD script. :-\

Edit: Was a missing closing }.

[AntumDeluge]

I'm not sure if it is going to work as a single PKGBUILD script:

$ pacman -S mingw-w64-x86_64-wxmsw3.1 mingw-w64-x86_64-wxwidgets3.0-msw mingw-w64-x86_64-wxwidgets3.0-msw-libs
resolving dependencies...
looking for conflicting packages...
:: mingw-w64-x86_64-wxwidgets3.0-msw and mingw-w64-x86_64-wxwidgets3.2-common are in conflict (mingw-w64-x86_64-wxwidgets-common). Remove mingw-w64-x86_64-wxwidgets3.2-common? [Y/n]
:: mingw-w64-x86_64-wxwidgets3.0-msw and mingw-w64-x86_64-wxwidgets3.2-msw are in conflict (mingw-w64-x86_64-wxconfig). Remove mingw-w64-x86_64-wxwidgets3.2-msw? [Y/n]

All dependencies can't be installed at the same time.

Edit: As I understand, normally wxWidgets builds can be installed side-by-side. But that doesn't seem to be the case with MinGW-w64 packages.

[AntumDeluge]

With how the current wxWidgets packages are set up, build dependencies conflict:

$ pacman -S mingw-w64-x86_64-wxwidgets3.0-msw mingw-w64-x86_64-wxwidgets3.2-msw
warning: mingw-w64-x86_64-wxwidgets3.2-msw-3.2.0-3 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: mingw-w64-x86_64-wxwidgets3.2-msw and mingw-w64-x86_64-wxwidgets3.0-msw are in conflict

And makedepends cannot be set inside package function:

==>  MINGW_ARCH: mingw64
    -> Building mingw64...
  ==> ERROR: makedepends can not be set inside a package function
  ==> ERROR: makedepends can not be set inside a package function
  
  [MSYS2 CI] FAILURE: mingw-w64-wxSVG: Building binary failed.

So I don't think it can be done without using separate PKGBUILD scripts currently.

[AntumDeluge]

  ==> Checking buildtime dependencies...
  ==> Installing missing dependencies...
  resolving dependencies...
  looking for conflicting packages...
  error: unresolvable package conflicts detected
  :: mingw-w64-clang-x86_64-wxwidgets3.2-msw and mingw-w64-clang-x86_64-wxwidgets3.0-msw are in conflict
  error: failed to prepare transaction (conflicting dependencies)
  ==> ERROR: 'pacman' failed to install missing dependencies.
  ==> Missing dependencies:
    -> mingw-w64-clang-x86_64-autotools
    -> mingw-w64-clang-x86_64-cc
    -> mingw-w64-clang-x86_64-wxwidgets3.0-msw
    -> mingw-w64-clang-x86_64-wxwidgets3.2-msw
  ==> ERROR: Could not resolve all dependencies.

[AntumDeluge]

I am giving up on this for now since there are dependency conflicts & going to create a PR for an updated wxSVG built against wxWidgets ~~3.1~~ 3.2.