Remove logic from outside build - 0.5.0 only

[ekrich]

The idea here is to not have any build or naming logic in the build file. We don't want all the build tools (sbt, Mill, Gradle, Maven, etc.) re-implementing the same logic.

This removes nativeLink / artifactPath which is called for every single project, scala version, and for normal and test configuration so that makes the sbt load much slower. Note: add a println of the value in the build and see for yourself.

The idea is also to internalize any caching or other tricks needed to speed up compilation. Even though build tools typically handle recompilation caching some of this is already in the build tools so I think this should be handled within. This is not planned for this PR however.

I would hope that we can finalize this and then attack the Library and Rust PRs after because they can build on this idea.

Note: we have this PR which may need considering. I don't quite understand the specific use in the Portsfile. #2362

[ekrich]

Now you can run the second task as well to show the entire build config.

show sandbox2_13 / nativeConfig

show sandbox2_13 / nativeBuildConfig

[WojciechMazur]

I really like this change, but let's schedule it for 0.5.0, it would be way easier for maintainers of the mill, scala-cli or other build tools to handle that.

[ekrich]

Sounds good. I need to change the artifact basename to be in the NativeConfig vs Config. I also think it might be nice to drop the -out for the executable, for the test executable too?

I plan to do some followup work to fix the discovery issues and capture the discovered items to speed up the build.

[ekrich]

I have heard rumblings about wanting C and C++ options separate and perhaps we can separate include and link paths from the options. Perhaps we should have the conformance option separate as well like the standard e.g. -std=c++11. I also plan to make discovery return the items that will be used for compiling and linking so if you want to augment/inspect/replace them then all these things are possible. This way we can remove settings from the build that can't be changed. In other words, you can pretty much set nothing or have complete control. I am also thinking about/formulating plans to allow each project to present options for that project read from scala-native.properties. This can allow the link filtering -D_MYDEF setting and other things to make the library developer better. We could also separate to GC and move some code around to the proper project.

I also plan to cache the discovery - it only needs to happen once (reloaded when the build is reloaded). Not sure how that works for different platfroms yet. With the properties file, we could also cache those for each sub-project to avoid extra computation. Also, checking time stamps on the native files could avoid recompilation similar to make.

[ekrich]

Check if this is supported for workdir - #2438

[ekrich]

@WojciechMazur This is ready for review. I would prefer to do several smaller PRs on the way to better tools rather than a big bang that is hard to review.