WIP: Meson/Maven build for MMCoreJ #696
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
marktsuchida
force-pushed
the
meson-mmcorej
branch
from
3182bcd to
ff83d76
Compare
15 tasks
marktsuchida
force-pushed
the
meson-mmcorej
branch
2 times, most recently
from
5ea8910 to
3e97b57
Compare
Member
Author
|
Removed Java compile/jar from Meson build and updated pom.xml so that Maven can build using SWIG Java sources generated by Meson. This way we don't have to manually mess with the jar/pom during build. The jars produced (artifactId = MMCoreJ) are the Java part only. Next steps:
|
marktsuchida
changed the title
marktsuchida
force-pushed
the
meson-mmcorej
branch
2 times, most recently
from
9b02c76 to
790a55c
Compare
marktsuchida
force-pushed
the
meson-mmcorej
branch
from
790a55c to
0c79a16
Compare
marktsuchida
force-pushed
the
meson-mmcorej
branch
from
0c79a16 to
2faa960
Compare
We'll leave that for Maven.
Put in more logical order. Also remove redundant packaging=jar (it's the default).
Could be scm:git:git@github.com or scm:git:https://github.com but not scm:git:git://github.com. At least not any more.
More concise name/description. Update/correct developer organizations.
This is needed for Maven to use them cleanly. Because SWIG fails if the outdir doesn't exist, use a Python wrapper to run SWIG.
- Point to SWIG-generated Java sources in builddir/ (hard-coded for now) - Remove obsolete Sonatype OSSRH config (will need to add Central Portal config later) - Update plugin versions
It's cleaner for the outer script to set builddir equally for Meson and Maven, so parameterize.
Until we have a proper way to address them, there're not helpful.
(Assisted by Claude Code; any errors are mine.)
There is not much point in pinning the mmdevice and mmcore commits until MMCoreJ is in its own repository and no longer in mmCoreAndDevices.
Without this, there is the danger of producing a jar with only the static sources. (Assisted by Claude Code; any errors are mine.)
(Assisted by Claude Code; any errors are mine.)
(Assisted by Claude Code; any errors are mine.)
Signing (among other things) will most likely be handled by JReleaser.
This has mainly 2 advantages for us: - It removes all the built-time profile/property settings, which could make the pom appear more complicated than it is for people looking to use MMCoreJ as a dependency. So flatten it to what a dependency resolver (Maven/Gradle) will actually see. - It can allow parameterizing essential values, such as version, by templating them and passing them in on the `mvn` command line.
marktsuchida
force-pushed
the
meson-mmcorej
branch
4 times, most recently
from
fe942b1 to
7a1191b
Compare
So that MMCoreJ's Meson build can access it to extract docs and convert to Javadocs.
Port the swig_doc_converter.py script from the micro-manager repo. Invoke from run_swig.py, because the plan is for SWIG 4 to replace this step in the future. (Assisted by Claude Code; any errors are mine.)
Mark some seldom-used options as deprecated. (Assisted by Claude Code; any errors are mine.)
That is, libmmcorej.{so,dylib} or mmcorej.dll.
Aside from being a cleaner name (we're wrapping MMCore, not MMCoreJ),
using a different name allows us to distinguish between the packaged
library (reliable) from one that might be left over from an older
installation (may be the wrong version). At some point we will be able
to remove the legacy loading code, after which 'MMCoreJ_wrap' will be
completely retired (except perhaps as the names of the SWIG-generated
C++ source).
(Once we set up extract-and-load from JAR, this name won't be seen much
by the user anyway.)
Do not change the name when built by Automake/VS, of course.
Copy NativeLibraryLoader from ihist.
Fall back to the existing ("legacy") search order.
See README for details.
(Assisted by Claude Code; any errors are mine.)
Slightly modified from ihist's tests. (Assisted by Claude Code; any errors are mine.)
marktsuchida
force-pushed
the
meson-mmcorej
branch
7 times, most recently
from
fd561ce to
45e8fe2
Compare
So that list in meson.build does not become stale. (Assisted by Claude Code; any errors are mine.)
Aim to produce packages correct for distribution, even though publishing (to Maven Central) will probably remain manual while MMCoreJ lives in the mmCoreAndDevices repo. Partially following ihist's setup.
This is needed to keep our URLs unbroken. (On Linux, CASE_SENSE_NAMES might default to YES, which produces, e.g., classCMMCore.html instead of class_c_m_m_core.html. While that is nicer-looking, it breaks existing links.) This is also needed for the swig_doc_converter.py script of MMCoreJ to work reliably.
marktsuchida
force-pushed
the
meson-mmcorej
branch
from
c164a8c to
4bdd99b
Compare
(Assisted by Claude Code; any errors are mine.)
(We missed it previously because it's only needed on older Linux, on which we've only tested building MMCoreJ.)
For manylinux build of MMCoreJ.
marktsuchida
force-pushed
the
meson-mmcorej
branch
from
4bdd99b to
77d73b5
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a work in progress.
The goal to aim for is a stand-alone mmcorej repository (initially a mirror of
MMCoreJ_wrap/) that is analogous to pymmcore, which publishes to the Maven Central repository.Major things remaining to do:
meson dist)pom.xmlwith version frommeson.build(probably not while MMCoreJ lives in mmCoreAndDevices)pom.xmlin jarThe Javadoc generation requires some thought. We currently use the ancient swig-doc-converter, which I'd like to retire. SWIG 4 can translate Doxygen to Javadoc, but (a) we still require SWIG 2/3 for MMCoreJ (#37) and (b) the doc comments of MMCore will need to be in the headers for that to work (#23 - probably best to do when no major PRs are outstanding on MMCore). Might be best to tackle those issues first.Let's keep swig-doc-converter for now so we don't need to switch to SWIG 4 yet here.