Mid-term: sbt-cross might give hints about handling 2-out-of-3 (m-out-of-N) issues.

[LeeTibbert]

Please pardon me if this is the wrong place to raise this issue for
consideration. On other projects, I have been turned back on
StackOverflow for attempting to discuss unreleased software.

At some point down the road, I believe that users of sbt-cross will
encounter a 2-out-of-3, more generally, m-out-of-N, problem
handling source directories, settings, etc. Examples of
solutions which do not fall into combinatorial complexity
will be useful to those users.

To get the existing sbt-cross trio project working with a
main program (1), I had to create a HelloWorld.scala
in each of bar/js/src, bar/jvm/src, and bar/native/src.
The js/src/HelloWorld.scala had to be different (until
I can figure out a better way). The bar/jvm and bar/native
files were identical, which violates DRY. To keep some
sanity, I do want to use symlinks.

Flush from success at getting the sbt-cross trio example
project working (Thank you for the example!), I tried to add
test tree code. Since it is, understandably, too soon for
scala-native to support uTest, I wanted to be prepared
and get up to speed by testing scalaJS vs scalaJVM.
Is there a better place for discussion?

This left me with a situation where I needed to enter
settings common to the scalaJS & scalaJVM sub-projects,
but not the scala-native project. Someday I may
be clever enough to figure out some elegant sbt/scala
code to do this, but for now I duplicated (and the
spirits of my mentors yelled at me, for good reason).

When I set up the testing directories, I ran into
a similar problem. I had to duplicate
the tree in js/src/test to jvm/src/test. Surely
a cause for future, self-inflicted pain.

I can also foresee situations where one would want
scalaJVM & scala-native in the mix and scalaJS out.

With time, I hope to figure out some clever way of
handling these 2-out-of-3 issues without falling into
combinatorial complexity. The sbt settings issue
is probably simpler than the duplicated tree issue.

I mention instances of this issue early on for "back of the brain'
consideration because I think other developers will
run straight into them as the try to stretch from the
well explored & experienced scalaJS/scalaJVM duo
to the nova mundi of scalaJS/scalaJVM/scala-native trio.

Thank you for any suggestions, including
"Please be patient until sbt-cross matures".

Lee

1. At this point, the sbt-native HelloWorld.scala is
   scaffolding and/or a thought experiment. sbt-native
   seems to have a problem and generate null output to stdout.
   In the fullness of time that will get fixed.

[sjrd]

FWIW, the settings problem already has a solution:

.platformsSettings(JSPlatform, JVMPlatform)(
    libraryDependencies += ...
)

(with the appropriate imports to import JSPlatform and JVMPlatform).

I agree we should figure out something for directories, though. Tricky one ...

[LeeTibbert]

@sjrd Thank you for the platformsSettings() info. I just got a chance to
try it out and it worked like a charm (as you certainly expected).

Now I have my common_settings, shared_by_2, and shared_by_none
dependencies nicely ordered.

I believe that this info gives me a toe hold into solving/reducing_the_strength of
my 2-out-of-3 source directory issue (by selectively appending to sbt's
unmanagedSources). Work in progress...

[MasseGuillaume]

If I understand correctly you want to minimize the distance between platform a and platform b sourcecode. One solution I can think of is the C preprocessor (#ifdef). We can find this implemented in Scalatest: Build Code.

[ghost]

We already have a "proper" platform ifdef in catalysts platform, using

final val makes compiler constant-fold any use of these values, dropping dead code automatically

Example in cats

It was actually @sjrd that suggested this approach, we had a macro before 😄

[MasseGuillaume]

@BennyHill Nice trick!

[ghost]

Nice trick!

Indeed - but it was all @non's inspiration !

[MasseGuillaume]

I think the only limitation is that you cannot use this trick to have a different api depending on the platform.

[ghost]

Sure, this module is really for those "micro" changes, ones that need to be different but are so small code wise it seems daft to change the entire directory structure to implement them. It's also useful when you might actually want to see the platform differences in the same file.

Settings are an obvious candidate here for both use cases.