CMakeFile wrong design.

[olahaye74]

• OS version: CentOS-8 (in fact, all distort may be affected)
• Compiler version: gcc-8.3.1 (all compiler affected)
• Package version: GitHub branch

Problem:
In order to package this utility, you need to build it with prefix=/usr and install in DESTDIR=/temp_dir/used/for/packaging.
install rule should install in $DESTDIR/$PREFIX/, but this isn't the case.
Even worse, if you try to set CMAKE_MODULE_PATH=/usr/sahre/cmake/Modules, it fails to build. If you don't provide it, it installs in local dir. No way to have Modules installed in proper destination ($DESTDIR/$PREFIX/share/cmake/Modules).

• Goal: have CMake design that permit packaging. makefile install: rule should honor DESTDIR.

when building an rpm, %cmake and %makeinstall macros are doing the following:
$ rpmbuild --eval %cmake

CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection}" ; export CFLAGS ;
CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection}" ; export CXXFLAGS ;
FFLAGS="${FFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules}" ; export FFLAGS ;
FCFLAGS="${FCFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules}" ; export FCFLAGS ;
LDFLAGS="${LDFLAGS:--Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld}" ; export LDFLAGS ;
/usr/bin/cmake
-DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG"
-DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG"
-DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG"
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
-DCMAKE_INSTALL_PREFIX:PATH=/usr
-DINCLUDE_INSTALL_DIR:PATH=/usr/include
-DLIB_INSTALL_DIR:PATH=/usr/lib64
-DSYSCONF_INSTALL_DIR:PATH=/etc
-DSHARE_INSTALL_PREFIX:PATH=/usr/share
%if "lib64" == "lib64"
-DLIB_SUFFIX=64
%endif
-DBUILD_SHARED_LIBS:BOOL=ON

%make_install
/usr/bin/make install DESTDIR=/home/admin-local/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64 INSTALL="/usr/bin/install -p"

In the rpm spec file, normal cmake based project would just do things similar to this and have files build to be run in /usr and installed in temp build dir:
%build
mkdir build
cd build
%cmake -DCMAKE_MODULE_PATH=%{_datarootdir}/cmake/Modules ..
%{__make} %{?_smp_mflags}

%install
%make_install

Doing so with iLCUtil results in make_install failing:
Install the project...
-- Install configuration: "RelWithDebInfo"
-- Up-to-date: /usr/./include
CMake Error at cmake_install.cmake:41 (file):
file INSTALL cannot set permissions on "/usr/./include"

[rete]

Hi @olahaye74,

thank for opening an issue. iLCUtil CMake modules are indeed a little bit old style CMake at the moment. The thing is that we have a whole software stack relying on this package, so changes are welcome but must be carefully implemented.

We never tried to packaged iLCUtil in a rpm (as far as I know). Also, most of path conventions, such as install prefix or cmake modules, were introduced many years ago here and this is the kind of thing a bit hard to make it evolving without risking to break part of the software stack installation.

The best way to go, would be to open a pull request with changes you'd need and discuss them in detail.
What do you think?