New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow setting jvm on a per project basis #319
Comments
It's going to be a "maybe" for now. Compiling for different jvms means starting multiple bloop servers, one for each JVM. In itself this is not that bad, but then nothing in the model prevents dependencies between say jvm19 module and a jvm17 module. That would require bleep to duplicate a lot of task graph things from deep inside bloop. I don't think the added complexity is anywhere near worth it for a niche use case. What I think is a better way forward is to use build rewrites to use a transformed variant of the build for another JVM. Theoretically we could mount these rewritten builds in an IDE, though some glue code is missing there. Currently you can compile, test, publish and so on such a transformed build. If you decide to try that right now, i think the exposed API will let you change pretty much everything except JVM, but i can find either a workaround or a patched version if you're keen on trying out this approach. |
Can you point me in the direction of these rewrites? I'm also trying to put together a plugin to add scoverage reports |
I'll give you some pointers tomorrow. Currently 🍺🌞 |
I think I have a good handle on the BuildTransformers now after making a ScoverageReport plugin using them, but I don't think they'll do what I need done. I would say that isn't bleep's fault, cause currently no Scala build system can do what I need done for my project. The structure of my project is as follows:
j17 and j19 depend on core, while runtime depends on j17 and j19. The runtime project is fairly simple and exists to choose j17 or j19 based on what jvm the user is running (both j17 and j19s classes are loaded, but since only the correct one is used, you don't get classnotfound or bytecode exceptions). This makes slinc rather painful to build and develop. Compiling or testing the whole project is a multi-step process involving switching between jvms and compiling/testing each subproject seperately. At this point it feels like splitting them up into seperate repositories will be the final solution, though that introduces the pain of having to use publishLocal while developing core/j17/j19/runtime. That's an especially nasty problem when using dynver 😮💨 |
Have you tried using the |
|
Why would |
Aligning and updating the versions between projects quite a bit of work mid-development. At least it has been in my experience. |
Bleep seems very interesting to me, and I'd like to use it as the build tool in my project Slinc. One thing that Slinc needs, that no build tool provides at present, is per-project JVM settings.
Slinc has subprojects in it that target specific jvms, putting jvm specific usage of the preview/incubator status jvm feature "foreign api". The code in these projects is naturally JVM specific: j17 can only be built on Java 17, j19 on Java 19, and so on.
Bleep's support for setting the JVM in the build file is a step towards that, but if it could be told to compile j19 with a specific java 19 that would be the best option for me.
The text was updated successfully, but these errors were encountered: