Open ctrueden opened 2 years ago
This issue has been mentioned on Image.sc Forum. There might be relevant details there:
https://forum.image.sc/t/migrating-from-fiji-clij-to-napari-pyclesperanto/54985/73
With scijava/pom-scijava-base@804fa6734871b402e55cce04833cd71c63d1b3cb, pom-scijava-base now defines naming conventions for javacpp- and jogl-based native classifier artifacts. With scijava/pom-scijava-base@81f583d6ac8e1b6b3eed5cd3a4c66146381be5ed, this naming is extended to support arm64/aarch64 (e.g. Mac M1).
It doesn't solve the naming discrepancies described above, but it does make dealing with item (3) in a platform-agnostic way easier from inside Maven POMs that extend pom-scijava.
There are at least four different places where platform naming comes into play:
Bare native libraries for ImageJ/ImageJ2/Fiji. The ImageJ Launcher detects the platform, and sets
java.library.path
to include a folderlib/<platform>
, which currently supports five values:lib/win32
,lib/win64
,lib/macosx
,lib/linux
, andlib/linux-amd64
. Here is the logic where that is defined.Native libraries wrapped in JAR files. The ImageJ Updater names the platforms slightly differently:
jars/win32
,jars/win64
,jars/macosx
,jars/linux32
, andjars/linux64
(there is alsotiger
, for long-obsolete old versions of Mac OS X). Definitions are here, used in various places around the Updater code. The Updater selects the appropriate platform, marking files automatically as suitable only for the matching platform, for things in the correctlib
orjars
subdirectory.Naming of native classifier JARs. For example,
jogl-all-2.3.2-natives-linux-i586.jar
. Highly inconsistent across projects in the wild. See here and here and here for more discussion. One detail of note is that pom-scijava-base defines a propertyscijava.platform.arch
which is generally equal to Java'sos.arch
except that for x86-compatible architectures (e.g.x86_64
,amd64
) it simplifies it down to simply the number (e.g.64
). But for non-x86 e.g. Mac M1's ARM 64-bit architecture it will be the fullos.arch
value e.g.arm64
.Subdirectory naming convention for native-lib-loader. The native-lib-loader project enables dynamic loading of native libraries from inside JAR files, so that the JARs describe above in (3) can have their wrapped natives loaded easily. We use it in projects like FLIMLib to easily utilize native code from Java. Unfortunately, it has its own incompatible naming convention as well, distinct from (1), (2), and (3) above.
I dislike the inconsistency in naming across these four areas, and would prefer to reconcile and standardize the naming where possible, particularly now that Mac M1 machines are in the wild using ARM architecture.