
<html>>Le lun. 7 oct. 2019 à 16:49, Cornelis Bockemühl <cornelis@bockemuehl.ch> a écrit :<br />><br />>> Thanks to both you and J Decker: I would say that this is still the part<br />>> that I understood! So basically the word "install" in cmake language could<br />>> be replaced by "copy" more or less in common human language - right?<br />><br />>Nope I oversimplified.<br />>This is not a bare copy, e.g. the runtime path (a.k.a. RPATH or RUNPATH) is<br />>updated as well.<br /><br />Well yes, I understood that there are "some" other things happening - and I<br />did not think about RPATH or RUNPATH - because so far I never cared for them...<br />At this moment I finally have a setup running where shared libraries are<br />simply copied over with configure_file - without care for RPATH etc. -,<br />and it's working finally!<br /><br />But definitely now like the inventors of cmake have thought it should, with<br />a lot reinventing wheels etc...<br /><br />>> But then, if it is about "installing" a "target", which is libraries in my<br />>> case, I would expect the shared libraries to be copied - no?<br />><br />>Yes the shared lib should be coped and its RPATH updated.<br />><br />>> And this is exactly what does not happen - for no obvious reason! Because<br />>> some days ago it even happened in my project ONCE - and then not any more.<br />>> But debugging is not easy because since that moment I changed many things,<br />>> and basically the reason for my question is that I have no clear idea what<br />>> EXACTLY should happen if I put a<br />>><br />>> install(TARGETS mylibrary)<br />>><br />>> into my CMakeLists.txt. Well, like you explained, and like what I also<br />>> thought I had understood: nothing should happen during the configure and<br />>> generate runs of cmake, and also not during the "ninja all" build run, but<br />>> only during the "ninja install". or else cmake --build . --target install<br />>> (which in turn calls ninja in my case). Indeed I observed that it does a<br />>> build for "all" first if the initial project is not up to date.<br />>><br />>> But then it tells me that it is successfully "installing" mylibrary, but<br />>> I see no shared library appearing in the install tree! Or rather: it<br />>> happened once, but not any more - and I should find out what is missing...<br />><br />>Are building out-of-tree? (Are your source tree and build tree separate dir?)<br />>If so, did you try removing the entire build tree and try again ?<br /><br />Yes, it's out of tree. And also I did this removal and rebuild!<br /><br />This is exactly how I realized my problem: I had done once an "install build"<br />that copied library files to the target - and everything looked find from then<br />on. Until I did that exercise - and realized that nothing is copied any more!<br /><br />And because I could not find any plausible reason why this library copying did<br />not happen any more, I gave this "install" business up for the moment...<br /><br />>May be there is probably some mixup with your install DESTINATION in your<br />>install command.<br /><br />The problem is that I did not even change anything in that part of the project<br />from the moment when it "accidentally" happened once...<br /><br />But sure, it is never pure magic: I MUST have done something "wrong"!<br /><br />>> My current workaround is indeed that I am trying to avoid the install<br />>> step altogether and build a crazy construction with configure_file stuff<br />>> in order to get the libraries to the right place - and I know pretty<br />>> well that this is NOT the way how things should be done properly. But I<br />>> am afraid I will be ready with this workaround way faster than I will<br />>> understand what is going on during this miraculous "install" process!<br />><br />>Provide us with a stripped down non-working example and we may dig into it.<br />>Otherwise it is very difficult to guess what is happening in your particular<br />>case.<br /><br />That's exactly my problem: I am working on a ParaView custom project, and<br />then trying to "derive" another one from the first! So there is nothing<br />to be easily "stripped down" - it is simply a monster project - and I am<br />almost sure if I am going to write a simple dummy project, everything will<br />just work fine...<br /><br />And this is why I was asking for a more thorough documentation that what<br />you can find at Kitware where not the processes are explained, but just<br />"what to do".<br /><br />So from what I see, if you start a cmake project from scratch, you can start<br />with simple concepts and add towards more complex ones, with growing<br />understanding. However, if you start to build on ParaView, you start in<br />the middle of an already highly complex project setup, with little documentation<br />than just examples - and the entire process feels a bit like learning<br />C++ with only the source code of a C++ compiler at hand: certainly possible,<br />but takes a horrible amount of time... ;-)<br /><br />Side remark: Regarding cmake, this is also the reason why some days ago<br />I was asking for certain improved functionalities for debug support, like<br />a way to simply dump a list of "current targets" (including imported!),<br />plus a way to dump also all valid "properties" of targets!<br /><br />Bottom line: Since such a documentation like I would like to find may not<br />even exist, I think I should be happy that I have a "somehow working"<br />solution for the moment!</html>