search

pharo-project / pharo

Pharo is a dynamic reflective pure object-oriented language supporting live programming inspired by Smalltalk.
http://pharo.org
Other
1.21k stars 355 forks source link

Enhancement: Add library versions to SystemReporter #16110

Open astares opened 8 months ago

astares commented 8 months ago

We already have infos about VM and Image in the SystemReporter.

Maybe we should also add a section to SystemReporter to report about the used library versions (Cairo, ...) so one can directly see them in the tool.

image

see https://github.com/pharo-project/pharo-vm/issues/466

jordanmontt commented 8 months ago

+1 Also, it would be nice to include for which architectures are those libraries built. I was having an issue compiling the vm, and it was, partly, because pharo was using a system library that was build for another processor architecture.

For example, CairoLibrary uniqueInstance versionString >> "1.14.12 arm"

astares commented 8 months ago

Do we have a list of all the libs that we use and that would require attention?

guillep commented 8 months ago

They are probably listed in the VM repository (as we bundle them). The other possibility is to enhance FFI to list the libraries that were loaded, and somehow force a common protocol to get the version. What if you do FFILibrary allSubclasses?

astares commented 8 months ago

Looks like there is no common protocol. Not all are able to understand #versionString or #libraryVersion

For LGitLibrary the version call (via #libssh2_version) fails on Windows:

image
guillep commented 8 months ago

Looks like there is no common protocol. Not all are able to understand #versionString or #libraryVersion

For LGitLibrary the version call (via #libssh2_version) fails on Windows: image

That does not look right. I doubt libgit exposes a libssh version. It's either really old code or a bad copy paste that was never tested.

LGitLibrary has a version method that returns an array (major minor patch).

LGitLibrary uniqueInstance version "#(1 6 4)"

Now, of course I wouldn't say this would be straight forward. Libraries evolved independently and organically. But enforcing some common API is good for tooling. What do you think?

Also, to think about, not all libraries out there will provide a way to get a version number. So we must design the API to consider an "unknown" version too.

astares commented 8 months ago

This was Pharo 11.0.0 Build information: Pharo-11.0.0+build.722.sha.7b1fe353f74b22e8aa4a429fe929f30e71e0fa86 (64 Bit) but yes I get the "#(1 6 4)" in P11 and P12 using the above expression.

Some libs are included but not used by standard image like DynamicLoader and subclasses. We have TFTestLibraryUsingSameThreadRunner and TFTestLibraryUsingWorker who belong to tests.

So at the moment AFAIK we have remaining: