A number of compiler sources assume that omr is a subdirectory of openj9

[dnakamura]

There are a number of places in the compiler sources which have includes of the form #include "omr/compiler/foo/bar.hpp" This assumes that omr exists as a sub-directory of openj9. This prevents us from performing out-of-tree builds. (see also eclipse-omr/omr#3189).

Offenders I have found so far:
compiler/runtime/Runtime.hpp
compiler/il/ILProps.hpp
compiler/il/ILOpCodeProperties.hpp
compiler/x/amd64/codegen/TreeEvaluatorTable.hpp

[DanHeidinga]

@mstoodle @fjeremic Will this cause a problem with the way the namespacing and search path design the JIT uses?

[mstoodle]

doesn't that path just assume that the directory that contains omr is on the compiler's include search path?

[mstoodle]

if you remove omr from these paths, then nothing in OpenJ9 will be able to specifically include the omr version of that header file...

For example, if you remove omr from openj9/runtime/compiler/runtime/Runtime.hpp then you'll cause an infinite include....The reason omr is there is to specially include OMR's compiler/runtime/Runtime.hpp

[mstoodle]

If we remove the omr then we'll need tor rename some of the files to smurf them with, e.g., OMR

Addendum: I did not add this comment to suggest we go down this path; i do not like this solution even though it is used within OMR itself.

[fjeremic]

I think we introduced the omr/ include prefixes because of #1992 (comment) by @mstoodle. The omr/ include assumes the contents of the runtime/ directory in OpenJ9 is a sibling to all of OMR, i.e. the directory looks like this:

/runtime$ tree -d -L 1
.
├── bcutil
├── bcverify
├── cassume
├── cfdumper
├── clear_vmi
├── cmake
├── codert_vm
├── compiler
├── cuda
...
├── omr // This is the entire OMR repository

[dnakamura]

Reworking the headers, so that the OMR version is named OMR<some_header>.hpp as is done with many of the other headers appears to work fine. Id be willing to open those PRs if people are alright with that solution

[fjeremic]

Reworking the headers, so that the OMR version is named OMR<some_header>.hpp as is done with many of the other headers appears to work fine. Id be willing to open those PRs if people are alright with that solution

@0xdaryl thoughts?

[mstoodle]

Doesn't the OpenJ9 build system already need to know where the omr repository is located? Why can't the directory containing OMR just be a configurable setting and passed in on the IPATH which makes the compiler layering solution a more or less consistent mechanism?

(for the record and to make it clear, I hate the idea to smurf file names with the project name in the project even though we still do it in places).

[mstoodle]

and, by the way, I think this issue is misnamed :)

[DanHeidinga]

@dnakamura What's the next step for this issue?

[dnakamura]

just #4928

[dnakamura]

Closing as last PR merged