Make bare setting loading order alphabetical

[eed3si9n]

Fixes #2697
Ref https://twitter.com/not_xuwei_k/status/1230140477959286848

Note that this is could potentially break an existing build that was relying on previous behavior, which seem to return build.sbt at the end if you have a.sbt, b.sbt, c.sbt, and build.sbt.

[dwijnand]

Fixes #2232 too?

[dwijnand]

Also:

Is ÿÿÿÿÿÿÿÿÿÿ~~~~dbuild~defs.sbt still last?https://t.co/P1SRncRm4O

— Dale Wijnand (@dwijnand) February 22, 2020

[eed3si9n]

I don't think it was ever the last:

> show Compile/scalacOptions
[info] * c
[info] * b
[info] * a
[info] * ÿÿÿÿÿÿÿÿÿÿ
[info] * build

with my patch it will be:

> show Compile/scalacOptions
[info] * a
[info] * b
[info] * build
[info] * c
[info] * ÿÿÿÿÿÿÿÿÿÿ

[eed3si9n]

If #2232 is still around, this won't fix it since this just changes the ordering of *.sbt files.

[dwijnand]

since this just changes the ordering of *.sbt files.

Isn't the criteria for #2232 "There should be a clear ordering on which one wins, or forbid initializing other subproject's keys."?

[dwijnand]

I don't think it was ever the last:

I find that very surprising, given dbuild introspects the build... Hmm, maybe it was discovered that naming convention didn't work, which is why they swiched to doing things onLoad? Maybe we should validate or talk to @cunei about it.

[eed3si9n]

Toni said:

This is not what I remember; the .sbt files used to be loaded in alphabetical order. It is the reason why the dbuild-specific file is called ÿÿÿÿ...: to be able to patch things after everything else loads. I don't know when/if sbt changed loading order, but this is my recollection.

[dwijnand]

I noticed yesterday from the output of loading that it definitely has build.sbt at the end. I can't remember anything being changes around sbt 1.0 times, so maybe this changed back when "no blankies" landed?