Open andre-caldas opened 6 months ago
Hi!
Could you provide steps to reproduce and environment (distro, compiler version, etc)?
Additionally some background of why you needed to customize CMAKE_INSTALL_PREFIX
would help.
Thanks.
Could you provide steps to reproduce and environment (distro, compiler version, etc)?
I use Debian unstable, but it seems my compiler is from "experimental". Environment info (with some superfluous data removed):
$ g++ --version
g++ (Debian 14-20240429-1) 14.0.1 20240429 (experimental) [gcc-14 r14-10144-g41d7a8ceaaa]
$ cmake --version
cmake version 3.29.3
Additionally some background of why you needed to customize
CMAKE_INSTALL_PREFIX
would help.
I don't really need... I just wanted to. :-)
I wanted to have everything installed to my local /home/andre/.local/
.
Everything worked fine and OGRE 4.0 is working, thanks to you guys. I also got OGRE installed to my .local
directory.
Trying to learn Ogre, I have noticed those files I have mentioned, but I don't really know what they are and how they affect me. :-)
I guess that regardless of my needs, CMAKE_INSTALL_LIBDIR
and the sort are supposed to be relative to prefix
. If not, it shall be considered a bug, IMHO. I have submitted a PR that follows the cmake
specs:
https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html
I assume you ran ?
cmake .. -DCMAKE_INSTALL_PREFIX=/home/andre/.local/
I don't really need... I just wanted to. :-)
Gotcha. The thing is this repo is only meant to build dependencies for ogre-next to pick up. By default this repo doesn't even install in any system path: it installs into a local folder (inside the build you told CMake).
And the main issue is that we'd have to test all platforms we support to ensure nothing broke.
That is why I will have to reject your PR unless you have objections.
Cheers Matias
And the main issue is that we'd have to test all platforms we support to ensure nothing broke. That is why I will have to reject your PR unless you have objections.
You do not need to officially support the thing. As per CMake documentation, the current version is wrong and the PR makes it right. This is regardless of anything. https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html
If you say you do not support PREFIX
... by observing the submitted PR you will notice that the patch actually removes certain mentions to the variable CMAKE_INSTALL_PREFIX
you claim not to support. If you do not support it, and the thing is actually wrong... nothing more correct than removing it. ;-)
But I do not have "objections". I am to new here to have "objections". But I do hope I have changed your mind. :-)
Just keep up the great work and I am happy! Please, feel very comfortable to make your decision. I shall not complain. :-D
I am not really familiar with
cmake
. I am very sorry if I am reporting something silly. :-)I have used
ogre-next-deps
. I have setupCMAKE_CXX_FLAGS
andCMAKE_INSTALL_PREFIX
. This is the content of mysrc/CMakeLists.txt
:Now, I have realized that the generated files
pkgconfig/shaderc*.pc
give a wronglibdir
:I do not really understand much... but I see two options:
@CMAKE_INSTALL_LIBDIR@
should simply belib
, but it is being configured with an absolute path. The file./build/src/shaderc-prefix/tmp/shaderc-cfgcmd.txt
contains-DCMAKE_INSTALL_PREFIX:PATH=/home/andre/.local;-DCMAKE_INSTALL_LIBDIR:PATH=/home/andre/.local/lib/;-DCMAKE_INSTALL_BINDIR:PATH=/home/andre/.local/bin/
.includedir
,${prefix}
should not be there either. And "two wrongs made a right", because@CMAKE_INSTALL_INCLUDEDIR@
is relative, not absolute.The template files are like this:
Maybe none of them (
libdir
orincludedir
) should have a${prefix}/
. It is strange, in my opinion, that@CMAKE_INSTALL_INCLUDEDIR@
actually gives a relativeinclude
path, instead of an absolute path. But this is also true forSYSCONFDIR
,DATAROOTDIR
, etc.I do not really know which one is the correct one. But making all those
XXXDIR
relative toPREFIX
is what makes more sense. In this case,BINDIR
andLIBDIR
are wrong.