Skip to content

Explore CBT #34

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

Open
mdedetrich opened this issue Jul 4, 2017 · 3 comments
Open

Explore CBT #34

mdedetrich opened this issue Jul 4, 2017 · 3 comments

Comments

@mdedetrich
Copy link
Owner

mdedetrich commented Jul 4, 2017

Due to portable-scala/sbt-crossproject#47 there might be a valid reason to explore using CBT (especially since CBT is going to be released as stable soon).

@jvican I just remembered, is this going to be an issue for the sbt-platform if we decide to use CBT instead of SBT?

@jvican
Copy link
Collaborator

jvican commented Jul 4, 2017

Yes, it's a problem because the Scala Platform infrastructure only supports sbt, and that includes all the MiMa checks, et cetera.

Personal use case is https://github.com/mdedetrich/scalajson, and I would like to support scala-js 0.6.18 and the new scala-js 1.0.0x (and also in general for scala-native various releases)

Can't you do this by creating different modules that share most of the source code from a project? It's a pretty advanced use case, but I think sbt can support it. Obviously, the sbt cross platform plugin cannot, but that doesn't meant that sbt can't by design.

@mdedetrich
Copy link
Owner Author

From what I understand it's not really possible to do in SBT because you are loading different versions of the same sbt plugin. (I can be wrong in this regard though). The documentation on Scale.js website implies that this isn't really possible because you have to use environment variables to alter the behaviour of the sbt-plugins outside of any.

Is there a sample project that demonstrates this is possible somewhere?

@mdedetrich
Copy link
Owner Author

mdedetrich commented Jul 5, 2017

Also I disagree with this being an advanced use case, similarly to how crossScalaVersions works, if a new release of scala-js/scala-native is made they should be able to release their library with that new version without having to bump the version of their own library.

You could argue that you can just replace the previous version, but then you don't have reproducible builds anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants