Skip to content

Cleanup installation targets #35

@dvrogozh

Description

@dvrogozh

After building IGC with the recommended steps:

$ cd build
$ cmake -DIGC_OPTION__OUTPUT_DIR=../igc-install/Release \
    -DCMAKE_BUILD_TYPE=Release -DIGC_OPTION__ARCHITECTURE_TARGET=Linux64 \
    ../igc/IGC
$ make -j`nproc`

I get the following layout:

.
└── Release
    ├── bif
    │   ├── embedder
    │   │   ├── IGCsize_t_32__igc_bif_BC_120.cpp
    │   │   ├── IGCsize_t_64__igc_bif_BC_121.cpp
    │   │   └── OCLBiFImpl__igc_bif_BC_122.cpp
    │   ├── IBiF_Impl_int.bc
    │   ├── IBiF_Impl_int.bc_IBiF_Impl__cl__0.bc
    │   ├── IBiF_Impl_int.bc_IBiF_Impl__cl__0.bc.tmp
    │   ├── IBiF_Impl_int_spirv.bc
    │   ├── IBiF_Impl_int_spirv.bc_IBiF_Impl__cl__0.bc
    │   ├── IBiF_Impl_int_spirv.bc_IBiF_Impl__cl__0.bc.tmp
    │   ├── IBiF_PreRelease_int.bc
    │   ├── IBiF_PreRelease_int.bc_IBIF_PreRelease_Impl__cl__0.bc
    │   ├── IBiF_PreRelease_int.bc_IBIF_PreRelease_Impl__cl__0.bc.tmp
    │   ├── IBiF_spirv_size_t_32.bc
    │   ├── IBiF_spirv_size_t_32.bc_pointersize__cl__0.bc
    │   ├── IBiF_spirv_size_t_32.bc_pointersize__cl__0.bc.tmp
    │   ├── IBiF_spirv_size_t_64.bc
    │   ├── IBiF_spirv_size_t_64.bc_pointersize__cl__0.bc
    │   ├── IBiF_spirv_size_t_64.bc_pointersize__cl__0.bc.tmp
    │   ├── IGCsize_t_32.bc
    │   ├── IGCsize_t_32.bc__link__0.bc
    │   ├── IGCsize_t_32.bc__link__0.bc.tmp
    │   ├── IGCsize_t_32_int.bc
    │   ├── IGCsize_t_32_int.bc_IBiF_size_t__cl__0.bc
    │   ├── IGCsize_t_32_int.bc_IBiF_size_t__cl__0.bc.tmp
    │   ├── IGCsize_t_64.bc
    │   ├── IGCsize_t_64.bc__link__0.bc
    │   ├── IGCsize_t_64.bc__link__0.bc.tmp
    │   ├── IGCsize_t_64_int.bc
    │   ├── IGCsize_t_64_int.bc_IBiF_size_t__cl__0.bc
    │   ├── IGCsize_t_64_int.bc_IBiF_size_t__cl__0.bc.tmp
    │   ├── igdclbif.bin
    │   ├── OCLBiFImpl.bc
    │   ├── OCLBiFImpl.bc__link__0.bc
    │   ├── OCLBiFImpl.bc__link__0.bc.tmp
    │   └── opencl_cth.h
    ├── clang
    │   └── linux-ubuntu64
    │       ├── clang
    │       ├── common_clang.h
    │       ├── libopencl_clang.so
    │       ├── module.modulemap
    │       ├── opencl-c-20.h
    │       ├── opencl-c-common.h
    │       ├── opencl-c.h
    │       ├── opencl-c-intel.h
    │       ├── opencl-c-platform-12.h
    │       ├── opencl-c-platform-20.h
    │       └── opencl-c-platform.h
    ├── elf_packager
    ├── fcl
    │   └── embedder
    │       └── opencl_cth_IDR_CTH_H_H_133.cpp
    ├── IntrinsicGenISA.gen
    ├── libBiFLibOcl.a
    ├── libCompiler.a
    ├── libCTHLibFcl.a
    ├── libGenISAIntrinsics.a
    ├── libiga64.so
    ├── libiga_enc64.a
    ├── libiga_s64.a
    ├── libigc.so
    ├── libigdfcl.so
    ├── libLocalScheduler.a
    ├── libSPIRV-Tools.a
    └── Tools
        └── GenX_IR

This is most definitely not something I am expecting to see on Linux. Could you, please, change the layout to the Linux standard one (see https://cmake.org/cmake/help/v3.6/module/GNUInstallDirs.html):

  1. Provide applications in the bin folder (CMAKE_INSTALL_BINDIR, defaults to bin)
  2. Provide dynamic libraries in the lib or lib64 or other standard folder (CMAKE_INSTALL_LIBDIR, defaults to lib or lib64 or lib/<multiarch-tuple> on Debian)
  3. Distribute other files accordingly

Other questions/concerns:

  1. Do you really need all the above targets for IGC or GenX_IR to be functional
  2. How I can make sure that GenX_IR lands nearby cm-compiler (it would be obviously so if you would follow standard practices)
  3. Why do you name your targets in the same way other standard package name them? clang is the most obvious example, elf_packager is the next suspect

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions