Since I’m in the process of learning more about indi, I spent some time trying to figure out why after building indi “sudo make install” copies the files to /usr/include/libindi, while on my notebook the files were copied to /usr/local/include/libindi. The only difference was that on one computer I built with the developer.bash script and on the notebook I used cmake .
I found out that with the developer.bash script around line 143ff the path is determined by: MAKE_INSTALL_PREFIX=/usr, while with cmake the script indi/scripts/indi-core-build.sh defaults to INSTALL_PREFIX=/usr/local.
I am just curious. Is this intentional? What is the reasoning behind it? Or is it an inconsistency that should be corrected?
The /usr file tree is (usually) for software that is managed by the package manager (apt, rpm). This is why the default for self-compiled programs is /usr/local, and needs to be overruled by an explicit parameter/keyword (as is done in that developer.bash script) . So things are correct as they are, and you’d have to either
cmake -DCMAKE_INSTALL_PREFIX=/usr ... or
export CMAKE_INSTALL_PREFIX=/usr
cmake ....
when using cmake yourself.
Hallo Peter,
thank you very much for your very informative answer.
I see and understand the underlying logic. I just thought that I “self-compiled” INDI in both cases
As a beginner with INDI, it is so fascinating how compact the documentation is written. The information you mentioned is already included in the README. I just didn’t realize it right away. The same statement (“compact” documentation) applies to many other details. Even after reading the documentation several times, I still do not see or understand all the details mentioned there.
All the best
Karl-Heinz
[quote=“Karl-Heinz”]Hallo Peter,
thank you very much for your very informative answer.
I see and understand the underlying logic. I just thought that I “self-compiled” INDI in both cases
[/quote]
Yes, you are right there. I don’t know the developer.bash script, but I assume it’s intention is to overwrite an installed version. The proper way would be to compile a new package for your distribution, and install that. But that can be a bit more complicated.