Build Requirements are incomplete

[mgaudet]

It seems that the build requirements aren't documented anywhere?

I have clang + CMake + make installed, but when following the instructions I get

matthew@xtower:~/personal/omr$ cd build
matthew@xtower:~/personal/omr/build$ cmake ..
-- Starting with CMake version 3.10.2
-- Found Git: /usr/bin/git (found version "2.17.1") 
-- The CXX compiler identification is GNU 7.4.0
-- The C compiler identification is GNU 7.4.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- OMR: The CPU architecture is x86
-- OMR: The OS is linux
-- OMR: The tool configuration is gnu
-- OMR: The target data size is 64
-- Looking for sem_init
-- Looking for sem_init - found
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc
-- Looking for clock_gettime
-- Looking for clock_gettime - found
-- OMR: trace root is '/home/matthew/personal/omr/build'
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE  
CUDA_TOOLKIT_ROOT_DIR not found or specified
-- Could NOT find CUDA (missing: CUDA_TOOLKIT_ROOT_DIR CUDA_NVCC_EXECUTABLE CUDA_INCLUDE_DIRS CUDA_CUDART_LIBRARY) 
-- Found LibZ: /usr/lib/x86_64-linux-gnu/libz.so  
-- Could NOT find LibElf (missing: LIBELF_LIBRARY LIBELF_H_INCLUDE_DIR) 
CMake Error at /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find LibDwarf (missing: LIBDWARF_LIBRARY DWARF_H_FOUND
  LIBDWARF_H_FOUND)
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
  cmake/modules/FindLibDwarf.cmake:107 (find_package_handle_standard_args)
  ddr/lib/ddr-scanner/CMakeLists.txt:47 (find_package)

-- Configuring incomplete, errors occurred!
See also "/home/matthew/personal/omr/build/CMakeFiles/CMakeOutput.log".

I can't seem to find documentation suggesting I need libdwarf, libelf, libz or cuda?

(These seem to be the blessed install instructions linked to from the readme)

[mstoodle]

You're right: we should update the list of pre-requisites. I knew about dwarf and elf, but somehow seem to have missed when libz and cuda became mandatory. And they should absolutely be documented! Thanks for pointing it out @mgaudet !

@rwy0717 @dnakamura could you please have a think about whether we really need all these to be compulsory requirements for every OMR consumer and then document the ones that need to be?

[mstoodle]

Randomly, I came across the PR that brought in the libz dependency, I think: https://github.com/eclipse/omr/pull/4267

[rwy7]

CUDA is purely optional, but libdwarf+libelf+libz are needed for DDR. Try turning off DDR with cmake -DOMR_DDR=OFF.

[charliegracie]

Maybe DDR should be turned off by default?

[mstoodle]

Thx @rwy0717 : I noticed that the CUDA dependency is just a warning (while I was building the JitBuilder release binaries :) ).

Agree with @charliegracie that we may want to turn DDR off by default (and document that when turned on, it pulls in the libdwarf+libelf+libz dependency).

[mstoodle]

If CUDA is "purely optional" then why does it print a warning if you don't have it? Is there another flag (OMR_CUDA?) that should also be disabled by default?

[rwy7]

OMR_CUDA is an optional feature of the port component, only enabled if cuda is found on your system. We could disable this feature by default, but I prefer the model where a component's optional features are automatically enabled when possible. These messages are generated by cmake when a dependency (via find_package) isn't found, even if it's optional. It's possible to silence, but I think this information is useful, if unfortunately verbose. Personally, I would rather just leave it alone.

If we want to turn DDR off by default, I don't really have an opinion, but do I think we need to have a broader discussion about what it means to build OMR "standalone" (for instance, why are any components enabled by default?).

EDIT:

• I'd be happy to open a PR disabling DDR by default, if we agree it's the Right Thing To Do™
• I don't know enough about DDR to document it's dependencies
• I can pretty up the "cuda not found" message (but I'd rather not remove it completely)

[mstoodle]

I've had a user request to "soften" the "cuda not found" message, so please let's do that. I created https://github.com/eclipse/omr/issues/4396 .

Documenting component dependencies is probably a larger issue we need to address across the board. I also created https://github.com/eclipse/omr/issues/4397 .

Any other opinions on disabling DDR by default?

[fjeremic]

Any other opinions on disabling DDR by default?

@keithc-ca any thoughts?

[keithc-ca]

The danger of disabling DDR by default is that OMR might accept changes that break DDR. I'd prefer to keep it enabled by default.

[keithc-ca]

I think the 'CUDA not found' message is due to the find_package(CUDA) added by #3808; I'm not sure what can be done to 'soften' that message.

I have mixed feelings about the current behavior: It's not clear that we'll get the right result if a user has more than one version of the CUDA toolkit installed. I understand there are ways to guide it to choose the one you want, but you'll need google's help to find them.

[mstoodle]

@keith-ca Disabling DDR by default and not doing builds with DDR enabled are two different things, so let's not confuse them.

I would be ok with most of our PR builds explicitly enabling DDR so long as we have at least one (say, an extra x86_64 linux build?) that builds with the defaults to make sure we aren't breaking that use case either. Thoughts?

[keithc-ca]

Agreed, as long as PR builds enable DDR it should be less likely to break. We may have to do something explicitly to ensure that's the case.

[rwy7]

Opened PRs #4403 and #4404.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment on the issue or it will be closed in 60 days.

[rwy7]

The building w/ cmake instructions are still out of date, so I am removing the stale label.