-
-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Derived new GenIdea module to support meta-builds #2638
Conversation
7ae829a
to
092fce8
Compare
ce3f846
to
552d312
Compare
TODO: deprectate the old module and update documentation
integration/feature/editing/test/src/MultiLevelBuildTests.scala
Outdated
Show resolved
Hide resolved
@lihaoyi Since we no longer need access to the |
Sure that seems reasonable |
This PR is now functional, yet the presentation of the project tree flipped from a more natural project representation to a more synthetic one. It looks almost arbitrary to me, why and when IntelliJ IDEA decides to use the other mode. But it's reproducible. I saw this kind of layout previously for some other projects, so it's not only determined by the current changes. This is the current (expected) layout for Mill repo: After applying this PR, the project layout looks like this: |
Could it be caused by differences in the generated XML files? I assume since the XML files are the only data passed from Mill to IntelliJ, any changes in Intellij's behavior must correspond to some change in the XML |
Probably yes, though not directly. I think it may be caused by the missing of a single root module, that sits at the project directory (mill-build is now in I will experiment a bit more with a top-level mill-build module. |
Could we create a dummy root module to see if it goes back to the original layout? I've seen the new layout sometimes too, and I find it very unintuitive to not have the whole project's filesystem structure available on the left, e.g. things like the `out/' folder that aren't mill modules but I still need to dig through sometimes |
The real difficulty is, that we don't have a specific way to tell IJ where a module lives. In very older versions, we used the I'd like to try a few more things, like mapping an empty content root, or mapping the |
I think I have found a nice compromise. I now add an additional but empty content root for each module, pointing at the You can see the restored natural Project view layout. Please note, that we now also have the tree nodes pointing to the various modules (not their sources) in bold, which might be unusual but IMHO isn't a bad thing. |
I reworked the generated modules a bit more and consolidated all content roots. I also tested this with a large-ish production-grade project, which uses lots of Mill plugins, meta-builds and customizations. Project layout, code navigation and meta-builds all work as expected and much better than before. |
Moved the implementation from
mill.scalalib
to a new modulemill.idea
. The reason is simple, we need access to therunner
module, butrunner
itself depends onscalalib
to provide compilation support. Generating an IDE setup has a much broader scope so a dedicated module is IMHO the best. This is analog tomill.bsp
, which also provides IDE support as a dedicated module.Deprecated the old
mill.scalalib.GenIdea
module.Enhanced the lookup for modules and root modules to reflect the new meta-build capabilities of Mill.
Reworked the XML generator to re-respect the
GenIdeaModule.intellijModulePath
setting and ensured we combine multiple source folders under the same source root if appropriate.GenIdea
#2633