[cmake-developers] [CMake 0015258]: 3.0.2-3.1rc2: _IMPORT_PREFIX always used even if absolute paths are in use - thus breaking build

Arkadiusz Miśkiewicz arekm at maven.pl
Tue Dec 9 02:34:23 EST 2014


On Monday 08 of December 2014, Stephen Kelly wrote:
> Arkadiusz Miśkiewicz wrote:
> > On Monday 08 of December 2014, Stephen Kelly wrote:
> >> Arkadiusz Miśkiewicz wrote:
> >> >> Removing CMAKE_INSTALL_LIBDIR from your command line might also cause
> >> >> the correct files to be generated (why are you setting that?).
> >> > 
> >> > To ensure correct libdir gets used/set the one defined in rpm (package
> >> > manager), not some kde/cmake one. Also user that uses rpm to build the
> >> > package is allowed to redefine it like rpm --define '_libdir
> >> > /blagblah', rpm passes that to cmake at cmdline.
> >> 
> >> Is there something equivalent for include dirs?
> > 
> > Yes, there is but it's not currently passed to cmake. libdir was passed
> > because of lib vs lib64 issue and problems related to it in the past.
> 
> You also pass -DLIB_SUFFIX=64. *Something* is redundant.

This is "one fits for all" type of setting. I remember that there were apps 
that used LIBDIR but didn't use LIB_SUFFIX while the other apps were using 
LIB_SUFFIX. So setting both defines made both apps happy.

> > I could set includedir too but probably there is some other xxxdir that
> > I'm not overriding and the whole problem will appear again, right?
> 
> Please help my understanding:
> 
> You justify passing the value of libdir because a user should be allowed to
> set it with rpm --define and you want to pass it along. However, if the
> user uses rpm --define to set the includedir, you don't pass it along,
> correct?
> 
> Why not?

libdir setting was needed due to lib vs lib64 issues there was no such issues 
with includedir. That's the only reason why libdir is set using rpm macro 
while includedir is not.

But you are right, this is not consistent and user trying to set includedir 
using rpm --define would fail for cmake case.

> I don't know if the problem would appear again with other paths/options. It
> is probably decreasingly likely after fixing the includedir.
> INTERFACE_INCLUDE_DIRECTORIES in IMPORTED targets is quite a new concept,
> but it will likely get widespread use.
> 
> Are there guidelines for creating rpms? Eg, can you point me to a guideline
> which says users should be able to pass 'rpm --define libdir ...'? Or is
> that kind of guideline only learned by doing but not written down?

There are no guidelines regarding rpm macros unfortunately. Every distro uses 
these in their own way.

With autoconf for example there is much more set from rpm side like:

[...]/configure %{_target_platform} --prefix=%{_prefix} --exec-
prefix=%{_exec_prefix} --bindir=%{_bindir} --sbindir=%{_sbindir} --
sysconfdir=%{_sysconfdir} --datadir=%{_datadir} --includedir=%{_includedir} --
libdir=%{_libdir} --libexecdir=%{_libexecdir} --
localstatedir=%{_localstatedir} --sharedstatedir=%{_sharedstatedir} --
mandir=%{_mandir} --infodir=%{_infodir} 

Not sure while cmake got only few dirs set here:

%{__cmake} \
        -DCMAKE_VERBOSE_MAKEFILE=ON \
        -DCMAKE_BUILD_TYPE=%{!?debug:PLD}%{?debug:Debug} \
        -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \
        -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \
        -DSYSCONF_INSTALL_DIR:PATH=%{_sysconfdir} \
        -DCMAKE_CXX_FLAGS_PLD="${CXXFLAGS:-%{rpmcxxflags} -DNDEBUG -
DQT_NO_DEBUG}" \
        -DCMAKE_C_FLAGS_PLD="${CFLAGS:-%{rpmcflags} -DNDEBUG -DQT_NO_DEBUG}" \
        -DCMAKE_Fortran_FLAGS_PLD="${CFLAGS:-%{rpmcflags} -DNDEBUG -
DQT_NO_DEBUG}" \
        -DCMAKE_EXE_LINKER_FLAGS_PLD="${LDFLAGS:-%{rpmldflags}}" \
        -DCMAKE_SHARED_LINKER_FLAGS_PLD="${LDFLAGS:-%{rpmldflags}}" \
        -DCMAKE_MODULE_LINKER_FLAGS_PLD="${LDFLAGS:-%{rpmldflags}}" \
%if "%{_lib}" == "lib64"
        -DLIB_SUFFIX=64 \
%endif
        -DBUILD_SHARED_LIBS:BOOL=ON \
%{nil}

Anyway I'm closer to solving this here in generic and hopefuly correct way.

> Thanks,
> Steve.

Thanks,
-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )


More information about the cmake-developers mailing list