[pietrygamat]

Addresses #211: additional tests focused on preventing #205 (wrong natives packaged into jar and sent to Maven Central).

I added multiple checks that run on different points of the lifecycle: because the release cannot just be built in a single run - we need to build natives in different environments, then there is an issue of tagging the git commit that the release version was built from. For this reason there are separate tests run against a binaries that were built this run, and separate that are run against natives we store in src and ship. The two commits (ignoring the required mac runner update) are:

1. Check the ident of the natives built in a run

#213 puts an ident into every native, but nothing reads it yet. This makes every build verify it's own output. NativeIdentTest class reads the marker so we can be sure the binary exist, is placed in right dir, built for arch we targeted - even in cross-compile build, where it cannot be loaded by java. Cross builds can't run the regular tests, so until now they ran none; they now run this one, and only this one. When build for host arch, the SerialNativeInterfaceTest also checks if the version reported by the loaded library is as expected. Some reorganization and additional properties in pom and ant/build were required to make the test trigger correctly only when natives are rebuilt, and also when natives are being rebuild with version different than the pom.xml - which happens during release preparation.

One aspect of the change is that it also verifiy if src/main/cpp/jssc_SerialNativeInterface.h is up-to-date against the SerialNativeInterface class. It was not - the header file in src (kept since #195) was obsolete, but keeping it up-to-date not only allows builds outside of java, but also allows us to identify native binaries as stale (if the header file was changed after commit imprinted in the rev field, we can tell without running). To avoild problems with keeping the file up to date, the build now puts the updated version of header file in src (only after significant change affecting C compilation). So the author of the change in SerialNativeInterfaceTest.class will be prompted to commit the header as well, and if they don't - the CI will reject the PR.

2. Verify the version and provenance of the natives before a release

A release ships the precompiled natives committed under src/main/resources-precompiled as they are. This adds the check that they were built for this release: PrecompiledNativesTest. Disabled by default, requires passing a flag to the mvn command. It is run in cross-compile.yml to verify all binaries are a matching set, and also during a release to Maven Central.

Run some test runs from my fork, the tests caught inconsistencies where expected (current master for example) and passed up to the maven central staging when natives are correct.

[pietrygamat]

Moved this section from cmake-generate section below. These props are now exported back to maven and to java/junit.

[pietrygamat]

Our java builds generate jni header and use it for compilation, so the committed one is unused. This part detects that the generated output is the same as the committed, and if not - replaces the committed one so the author of the change may commit it and keep in sync. I run tests against JDK 8, 11, 17, 21 and 25 and confirm, they all produce identical output, so this should not randomly change, but with one quirk:

The header generator distinguishes between Windows and other OSes, so on Windows the headers have 1 difference:

            case LONG:
                // Visual C++ supports the i64 suffix, not LL.
                valueStr = value.toString() + ((isWindows) ? "i64" : "LL");
                break;

This is a compatibility layer that to my research, is a relic of 1998 era of MSVC compilers, and the LL format works on any modern compiler including Windows. Our repo has a header with LL commited, and non java raw cmake build works.

// ours:     #define jssc_SerialNativeInterface_ERR_PORT_BUSY -1LL
// windows:  #define jssc_SerialNativeInterface_ERR_PORT_BUSY -1i64

We don't want Windows users see this as a change, and especially to make them commit i64 which I found is NOT accepted on Linux, so the code above replaces i64 -> LL - I could not find a pattern that would cause a false positive.

Anyway, the header that current build generates is still one that the compiler uses, so the replacement is a form of tracking changes in the repo rather than a rewrite of the compilation process.