Skip to content
This repository has been archived by the owner on Sep 19, 2021. It is now read-only.

Cross Build for SBT 1.0.0 #18

Closed
swachter opened this issue Aug 17, 2017 · 12 comments
Closed

Cross Build for SBT 1.0.0 #18

swachter opened this issue Aug 17, 2017 · 12 comments

Comments

@swachter
Copy link

No description provided.

@xuwei-k
Copy link
Member

xuwei-k commented Aug 17, 2017

http://www.scala-sbt.org/1.0/docs/sbt-1.0-Release-Notes.html#Improvements

Replace cross building support with sbt-doge. This allows builds with projects that have multiple different combinations of cross scala versions to be cross built correctly. The behaviour of ++ is changed so that it only updates the Scala version of projects that support that Scala version, but the Scala version can be post fixed with ! to force it to change for all projects. A -v argument has been added that prints verbose information about which projects are having their settings changed along with their cross scala versions. #2613 by jroper

@dwijnand
Copy link
Member

In other words: sbt-doge has been folded into sbt 1, so it's no longer required. That's why there's no release of it for sbt 1.

@ruippeixotog
Copy link

@dwijnand I'm trying to migrate from sbt-doge to SBT 1.0, but I can't find a way to replace strict aggregation (+++). Using it seems to be the only way to build a project for a specific version (a thing usually done in Travis builds) in typical setups of a root project aggregating all sub-projects. Am I missing something?

@dwijnand
Copy link
Member

From sbt-doge's README:

sbt-doge adds strict aggregation command plz. plz 2.11.5 compile will aggregate only the subproject that contains 2.11.5 in crossScalaVersions. The alias for plz command is +++ for CrossPerProjectPlugin.

From help ++ in sbt 1:

++ [!] [-v] []
Changes the Scala version and runs a command.

Sets the scalaVersion of all projects that define a Scala cross version that is binary
compatible with and reloads the build. If ! is supplied, then the
version is forced on all projects regardless of whether they are binary compatible or
not.

If -v is supplied, verbose logging of the Scala version switching is done.

If is provided, it is then executed.

++ [=][!] [-v] []
Uses the Scala installation at by configuring the scalaHome setting for
all projects.

If is specified, it is used as the value of the scalaVersion setting.
This is important when using managed dependencies. This version will determine the
cross-version used as well as transitive dependencies.

Only projects that are listed to be binary compatible with the selected Scala version
have their Scala version switched. If ! is supplied, then all projects projects have
their Scala version switched.

If -v is supplied, verbose logging of the Scala version switching is done.

If is provided, it is then executed.

See also help +

I think it means that sbt 1's ++ is sbt-doge's +++ - but I'm not sure.

@ruippeixotog
Copy link

From my experience, "Only projects that are listed to be binary compatible with the selected Scala version have their Scala version switched" when I use ++, but it doesn't remove from aggregations the projects that aren't binary compatible - they are still there, but they use their original version.

If you want I can build a minimal example showing the problem.

@ruippeixotog
Copy link

There seems to be no replacement for doge's strict aggregation in SBT 1.0 and implementing the logic to our projects is far from trivial, judging from the machinery in this plugin.

@dwijnand is there a chance that you might cross compile and publish sbt-doge for SBT 1.0, since not all features were ported to the SBT 1.0 core? Can you reopen this issue until then so that users may easily find this information if they are looking for ways to port their builds like me?

@dwijnand
Copy link
Member

Can you reopen this issue until then so that users may easily find this information if they are looking for ways to port their builds like me?

Yep. Done.

is there a chance that you might cross compile and publish sbt-doge for SBT 1.0, since not all features were ported to the SBT 1.0 core?

I'm not totally against doing that, but I wonder if perhaps a better way forward is to fix/add this to sbt 1 proper. Thoughts, @eed3si9n / @jroper?

@dwijnand dwijnand reopened this Oct 24, 2017
@eed3si9n
Copy link
Member

I named sbt-doge as doge because it was meant to be a proof of concept / hack to demonstrate the problem with sbt's aggregation, and not a serious plugin.
Now that it's fixed in sbt 1, we can remove this silly plugin. If people want additional feature that was later added by James, I'd recommend someone take the code and make a new plugin.

@jroper
Copy link
Member

jroper commented Oct 25, 2017

I'd say it should be fixed in sbt, but I'm not sure what the fix is - my big question is whether anyone depends on the current ++ behaviour, or if we can just modify ++ to do strict aggregation. I'm not sure why anyone would want the current ++ behaviour and not strict aggregation, originally when I implemented strict aggregation, I just modified the existing ++ command, but then on @eed3si9n's advice we created the new +++ command for it. Based on the discussion:

#4

I don't think a lot of thought was put into it by either of us.

If anyone can come up with a reason that ++ shouldn't be modified to have sbt-doges +++ behaviour, then maybe we could talk about an alternative solution, but short of that, I'd say the solution is to modify ++ to have the +++ behaviour.

But I completely agree with all the reasons above not to cross build sbt-doge against sbt 1.0. sbt-doge was a fork of sbt 0.13's cross build support, we've gone to all the effort of merging it back into sbt (which wasn't trivial and had a lot of teething issues that needed to be fixed), the last thing we want is to resurrect the fork and be back in the same place that we were before.

@ruippeixotog
Copy link

I fully agree that this behavior should be in sbt, not in a plugin.

I also think that the default behavior of ++ should be to do strict aggregation as I find it difficult to imagine an useful cross-project aggregation project otherwise. For compatibility purposes, would it be difficult to add a strictAggregation sbt boolean setting that changed the behavior of the operator?

@SethTisue
Copy link
Member

I would suggest a prominent section be added to the README in this repo explaining the situation w/r/t sbt 1

@ruippeixotog
Copy link

I opened sbt/sbt#3698 in order to continue this discussion.

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

No branches or pull requests

7 participants