These modules are certainly an annoyance in the build. Please file a bug
with this concern.
/Erik
On 2017-11-28 03:16, Maurizio Cimadamore wrote:
Some more specifics - these lines in the makefiles
(CompileJavaModules.gmk) are used to workaround the layout oddities:
ifeq ($(MODULE), jdk.internal.vm.ci)
## WORKAROUND jdk.internal.vm.ci source structure issue
JVMCI_MODULESOURCEPATH := $(MODULESOURCEPATH) \
$(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \
$(wildcard $(TOPDIR)/src/$(MODULE)/share/classes/*/src)))
MODULESOURCEPATH := $(call PathList, $(JVMCI_MODULESOURCEPATH))
endif
ifeq ($(MODULE), jdk.internal.vm.compiler)
## WORKAROUND jdk.internal.vm.compiler source structure issue
VM_COMPILER_MODULESOURCEPATH := $(MODULESOURCEPATH) \
$(subst /$(MODULE)/,/*/, $(filter-out %processor/src %test/src
%jtt/src %bench/src %microbenchmarks/src, \
$(wildcard $(TOPDIR)/src/$(MODULE)/share/classes/*/src)))
MODULESOURCEPATH := $(call PathList, $(VM_COMPILER_MODULESOURCEPATH))
endif
ifeq ($(MODULE), jdk.aot)
## WORKAROUND jdk.aot source structure issue
AOT_MODULESOURCEPATH := $(MODULESOURCEPATH) \
$(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \
$(wildcard $(TOPDIR)/src/$(MODULE)/share/classes/*/src)))
MODULESOURCEPATH := $(call PathList, $(AOT_MODULESOURCEPATH))
endif
Now, I'm fine with this module having a non-standard layout, but I
think it would be great if the build could paper over those
differences and yield a set of make variables that looks like that of
any other module. More importantly, the sources above are not returned
by a call to FindModuleSrcDirs, (e.g. MODULE_SRC_DIRS is not set
correctly for these) and I think they should.
Maurizio
On 27/11/17 19:14, Maurizio Cimadamore wrote:
Hi,
the IntelliJ support for JDK relies on make to give the set of source
roots used for any given modules. I have noticed that the set of
source roots associated with 'jdk.internal.vm.ci' is incorrect, as it
points to
src/jdk.internal.vm.ci/share/classes
while in reality it should point to a subset of directories contained
in such a folder (depending on the architecture).
This breaks the IntelliJ project configuration if jdk.internal.vm.ci
is selected - which is causing issues for some, see [1].
[1] -
http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-November/000590.html
Maurizio