[groovy] Remove bundled groovy/apache commons binaries

[fuzzard]

Description

Update Groovy/Apache commons binaries, and dont ship in tree

Motivation and context

Remove binaries from git tree and download from mirrors (or from provided local/remote url)

The following defines (-D) can be set to point to existing extracted instances
(eg -Dgroovy_SOURCE_DIR=/usr/share/groovy)

groovy_SOURCE_DIR
apache-commons-lang_SOURCE_DIR
apache-commons-text_SOURCE_DIR

@wsnipex @basilgello Ive tried to implement a way for system maintainers to supply the groovy/apache-commons binaries as defines for offline install. Let me know if its not suitable or whatever.

The reasoning for all this is for a more streamlined way to bump binary files, rather than someone extracting and adding in tree and no real way to verify/validate easily.

How has this been tested?

Build macos aarch64

What is the effect on users?

N/A

Screenshots (if appropriate):

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• Student submission (PR was done for educational purposes and will be treated as such)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[basilgello]

Debian still ships 2.4 so I revert Jose's patches there. Will check and report back.

[fuzzard]

Debian still ships 2.4 so I revert Jose's patches there. Will check and report back.

So this isnt swig as such, these are binaries used for the groovy code generator after the swig usage.

https://commons.apache.org/proper/commons-lang/download_lang.cgi
https://commons.apache.org/proper/commons-text/download_text.cgi
https://groovy.apache.org/download.html

for the relevant packages. No idea if the apache commons stuff will be packaged in the debian world or not, but i imagine groovy is at least

edit: i guess debian packages them already, saw commons-text here https://packages.debian.org/source/sid/commons-text

[fuzzard]

From a distro building perspective, whats better as a definable option @basilgello , pass the tarball, or set the file for each directly? None of it is needed past build, so i imagine its simpler as a tarball?

[wsnipex]

if binaries are available in the distro, using them is always preferred from a packaging perspective. Using tarballs means having to include them in the source package.

[fuzzard]

Ive had a rework of this. Instead of allowing redirection of the tarball, a user can just set folder for the existing package contents (eg predownloaded/extracted, or system packages).

-Dgroovy_SOURCE_DIR=/usr/share/groovy
-Dapache-commons-lang_SOURCE_DIR=/usr/share/java
-Dapache-commons-text_SOURCE_DIR=/usr/share/java

This is based off debian packaging such as https://packages.debian.org/bookworm/all/groovy/filelist https://packages.debian.org/bookworm/all/libcommons-lang-java/filelist

Theres no need to specify (or know) about the version of each of the 3 packages from a distro perspective any longer, however it does just do a blanket add to the classpath of the above *_SOURCE_DIR paths. I dont think theres going to be issues, but who knows.

Ive also set it up to respect existing extractions (from DEPENDS_PATH), and also to save any downloaded tarballs to TARBALL_DIR for caching of the download. This should give us the benefit of updating them easier, but also reduce redownload/extraction where appropriate.

Hopefully this gives enough flexibility from a distro packaging perspective @wsnipex @basilgello

[fuzzard]

One thing i did try to do was to use NATIVEPREFIX, as the packages arent arch specific (ie java), but also they are only executed on build host, however not all platforms set NATIVEPREFIX (ie linux) so ive just gone with DEPENDS_PATH for now.

[wsnipex]

Looks good, but needs KODI_MIRROR to be defined for downloading when *_SOURCE_DIR isn't set (on non-depends builds)

[fuzzard]

God damn addon cmake gets me again, haha.

xbmc/cmake/scripts/common/PrepareEnv.cmake

Lines 5 to 8 in 00ebe66

	# in case we need to download something, set KODI_MIRROR to the default if not already set
	if(NOT DEFINED KODI_MIRROR)
	set(KODI_MIRROR "http://mirrors.kodi.tv")
	endif()

Its probably a good thing to add that to core as well i guess rather than hardcoding it

[basilgello]

Yup, better to vore it and make overridable if needed

[fuzzard]

Haved added KODI_MIRROR definition as a commit. I think it should rightly be available fairly early on, and couldnt think of a better included location, so have just added to root CMakeLists.txt.

As i would also just forget, ive changed the 2 locations where it would be suitable in core in this PR. One in an externalproject_add macro for dependencies, and the other is the setting of KODI_MIRROR in the patch find module. Its no longer needed, as KODI_MIRROR is now defined in addon PrepareEnv.cmake and core appropriately.

A todo is to potentially propagate KODI_MIRROR supplied to windows build scripts into the cmake project, but thats one i dont really care about right now, and if i dont remember it later, no harm.

[wsnipex]

God damn addon cmake gets me again, haha.

xbmc/cmake/scripts/common/PrepareEnv.cmake

Lines 5 to 8 in 00ebe66

	# in case we need to download something, set KODI_MIRROR to the default if not already set
	if(NOT DEFINED KODI_MIRROR)
	set(KODI_MIRROR "http://mirrors.kodi.tv")
	endif()

Its probably a good thing to add that to core as well i guess rather than hardcoding it

this is too late. We have to move this earlier in the chain. Probably best to move it to CMakeLists as an option and remove the various instances where this is set again.

edit: sorry, you did that already :)