Maybe Cross should not change millSourcePath

[lolgab]

Cross allows you to dynamically create multiple modules depending on a variable.
One common example is cross-compiling for multiple versions of Scala.
You can do something like:

object module extends Cross[Module]("2.13.10", "3.2.1")
class Module extends CrossScalaModule

and you can compile and build everything twice for the two Scala versions.

CrossScalaModule has some magic in it, so the source directory doesn't change if you want to start
cross-compiling an existing module.

When you want to use Cross with some other variable, a side effect happens.

Imagine you have a java module like this:

object module extends JavaModule

Now you want to build two different modules based on a mode string:

object module extends Cross[Module]("development", "production")
class Module(mode: String) extends JavaModule

If you do this Mill doesn't find the code anymore, so the compilation succeeded, but no file was compiled.

This happens because in Cross there is this setting.

millSourcePath = ctx.millSourcePath / relPath

Which changes the source path from:

T.workspace / "module"

to

T.workspace / "module" / "production" // for "production" module
// or 
T.workspace / "module" / "development" // for "development" module

CrossScalaModule doesn't suffer from this problem since the setting is overridden here with:

override def millSourcePath = super.millSourcePath / os.up

Now the question:
What if Cross stopped to change the millSourcePath and if users really need this, they would need to do it manually?
Of course, this would be a breaking change, and a dangerous one so needs to be communicated properly in case we perform this change.

[lefou]

I like the proposal, and I think it better reflects how Cross is used in the wild. E.g. in all of my Mill plugins I also have a itest module to run integration tests against various supported Mill versions, and I always end up with overriding the millSourcePath to what it would be, if it were no cross module.

I agree, that compatibility is the greatest concern here. I think not that many users expect the current behavior, so for them an updated documentation is probably enough. We should concentrate on users migration older existing setups, as these are going to not function as expected any longer. Beside the changelog, we should introduce a new section to the documentation describing what action is needed to switch to Mill 0.11.

In case we settle with this change, we should dedicate an own milestone release, so we can easier play around with it and also can deduce from the version explicitly what project changes are needed.

[lefou]

Here is my take:

• Do not add Cross matrix items to millSourcePath #2347

[lefou]

Implemented and released as Mill 0.11.0-M5.