[CMake] Suppress a specific path in the RPATH of an executable explicitly
In a project setup I am copying a number of shared library files into the executable directory (basically with a mechanism involving configure_file - because the "install" logic was simply too complicated for the project and for my limited brain capacity!). On a Windows system this works nicely, but on a Linux system there is always some logic that puts the original shared library location into the executable's RUNPATH, with the effect that they are not found in the place where they are supposed to be found. I tried to avoid this by using set_target_properties( PROPERTIES CMAKE_SKIP_RPATH TRUE)However, any effect was not visible: the "old" path is still included in RUNPATH. Maybe I overlooked one more imported target, overriding the effect of above, or it does not work on imported targets at all. Anyway, it would be much easier if I could simply drop one specific path explicitly with some setting! Dropping all is again too much - because I need other entries for other libraries. Is there such an option available? Maybe a workaround would be to explicitly prepend "$ORIGIN" to the RUNPATH in the executable: In this way the shared libs would be found in the executable directory first and any other "wrong" paths would not hurt. Many thanks and regards, Cornelis Bockemühl -- Powered by kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
Re: [CMake] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language
After stripping down the question to "can I install an imported target"? - with the purpose to copy the shared libraries also into the lib directory of the importing project - I could actually also use Google and look for an answer that somebody else might have been asked. And indeed: this seems to be a rather common question! And the "official answer" seems to be something like "this bug is a feature". It must have been a change request already years ago, and it was refused with different arguments, like: 1) proper RPATH handling is not possible in this case, because CMake cannot know the way how the shared library was built initially, so it is not able to manipulate it. At first this looks plausible, but then I was thinking that in Linux you always deal with ELF binaries, and there you have tools to manipulate RPATH/RUNPATH easily, and in Windows there is nothing similar - and others I don't know... 2) the target is already installed, so it makes no sense to install it again; it would only be a waste of disk space. Well, in my case it would make a lot of sense, and also for any kind of packager that might use the install directory it would be much easier if all the stuff is already in one location. 3...) maybe others - I did not follow further. In any case the conclusion is: It's like it is, and all my confusion came basically from this strange behaviour - that "install" is not always really "install" (but now I know at least when and why!). And the only way around - if I want to avoid the configure_file solution - would be to do some proper install(FILES...) instead - together with a little hacking regarding what the right files actually are. Best regards, Cornelis -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language
Actually I implemented yesterday a way how to copy the shared libs - with
configure_file() and a lot of frickling around with the lib names myself, like
finding out the extension on Linux and Windows, etc.
Now I tried to include the following command in the "shlibbiConfig.cmake.in"
file:
install(TARGETS shlibbi::SHLIBbi
EXPORT
shlibbi-targets
LIBRARY DESTINATION
${CMAKE_INSTALL_LIBDIR})
With this, I would expect that I am not "copying files", but "installing
targets" - so actually a more abstract and powerful level - if it works! Since
the generated shlibbiConfig.cmake would finally run in the context of the
importing project, i.e. during a find_package() call, it should actually
transfer the lib files from that imported target into the CMAKE_INSTALL_LIBDIR
of the calling project - so exactly what I need.
However, the result is an error message:
install TARGETS given target "shlibbi::SHLIBbi" which does not exist.
Well, it exists, because it is generated in the auto-generated
shlibbiTargets.cmake file like this:
add_library(shlibbi::SHLIBbi SHARED IMPORTED)
and that shlibbiTargets.cmake was called inside shlibbiConfig.cmake BEFORE the
above install(TARGETS...) call.
Conclusion: "imported targets" are not "fully valid targets", because while I
can now refer to that imported target, like with an #include ... in my source
code, or with a successful link to the library, but obviously I cannot
"install" that target.
So my question can be even more specified now: Is there a way around this
"install blockage" that would allow me to do the required transfer of the
shared library into the lib folder of the calling project - and then even
further also to the caller's calling project? I mean: with the effect of first
moving libshlibbi.so to the lib directory of the shlibbu project, and then both
the libshlibbi.so and the libshlibbu.so to the example project - of course
including the required adaptation of the RPATH
Because that is what I learned: doing the transfer with install() instead of a
file copy through configure_file gives me not only the more abstract level of
project organization, but also takes care of the RPATH...
Best regards,
Cornelis
Am Dienstag, Oktober 08, 2019 14:07 CEST, cornelis
schrieb:
Thanks for that hint! But for me the RPATH stuff is only a supplement, because
in the context of a Paraview based project, most of my shared libs are plugins,
and for these PV comes with its own mechanism to find them. But then all the
more important is the question about actually copying the libs - to a specific
location where the plugin finding procedure finds them! Regards, Cornelis
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language
One more finding: the "magic" that QtCreator does to start example also without any additional fiddling with the RPATH: it already contains a RUNPATH, and this points to the shared library libshlibbu.so in it's build tree location, not in the installed location - and the same with libshlibbu.so. And the "install" process indeed handles the RPATH/RUNPATH: it simply removes it! Meaning: it I want to end up what I initially expected, I have to do two additional things manually (or maybe there is an automatic way??): 1) copy the shared libraries to the "example" install directory tree 2) add some RPATH or RUNPATH setting to all the binaries that need it Regards, Cornelis -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] ?==?utf-8?q? ?==?utf-8?q? ?= Looking for an explanation: What exactly means "install" in cmake language
The missing link to my "cmake teacher web page": https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/ Regards, Cornelis -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] ?==?utf-8?q? Looking for an explanation: What exactly means "install" in cmake language?
> I think that the word install is used consistently between GNU autotools and > CMake: Right, looks like it comes from the "good old times" when on Linux computers software was "installed" by downloading, then doing a "make" and a "make install" in order to get it running, while nowadays "installation" is normally done by a package manager that tries to resolve dependencies and works with binaries only. And CMake does some tricky things to do an "install" in order to later on "export" and "import" the code, or prepare it for "pack" etc. > It's that "prepare it for..." clause that makes it different from a straight > up copy. In my case it looks like it "somehow works" for now without other preparations - but I hate this "solution" because it is against all "good cmake use" that would rather deal with targets and properties only, not with variables and directly copying files around, fiddling with shared library extensions (like so or dll) - but if working "the right way" takes so much time to figure out, it's finally a question of time economy that you finally end up with doing it "the hard way". (...which is of course the opposite of what a build tool should do for you: It should not make project setup more complicated, but more simple! But well - that's the real world ;-) ) -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] ?==?utf-8?q? Looking for an explanation: What exactly means "install" in cmake language?
>Le lun. 7 oct. 2019 à 16:49, Cornelis Bockemühl a >écrit : > >> Thanks to both you and J Decker: I would say that this is still the part >> that I understood! So basically the word "install" in cmake language could >> be replaced by "copy" more or less in common human language - right? > >Nope I oversimplified. >This is not a bare copy, e.g. the runtime path (a.k.a. RPATH or RUNPATH) is >updated as well. Well yes, I understood that there are "some" other things happening - and I did not think about RPATH or RUNPATH - because so far I never cared for them... At this moment I finally have a setup running where shared libraries are simply copied over with configure_file - without care for RPATH etc. -, and it's working finally! But definitely now like the inventors of cmake have thought it should, with a lot reinventing wheels etc... >> But then, if it is about "installing" a "target", which is libraries in my >> case, I would expect the shared libraries to be copied - no? > >Yes the shared lib should be coped and its RPATH updated. > >> And this is exactly what does not happen - for no obvious reason! Because >> some days ago it even happened in my project ONCE - and then not any more. >> But debugging is not easy because since that moment I changed many things, >> and basically the reason for my question is that I have no clear idea what >> EXACTLY should happen if I put a >> >> install(TARGETS mylibrary) >> >> into my CMakeLists.txt. Well, like you explained, and like what I also >> thought I had understood: nothing should happen during the configure and >> generate runs of cmake, and also not during the "ninja all" build run, but >> only during the "ninja install". or else cmake --build . --target install >> (which in turn calls ninja in my case). Indeed I observed that it does a >> build for "all" first if the initial project is not up to date. >> >> But then it tells me that it is successfully "installing" mylibrary, but >> I see no shared library appearing in the install tree! Or rather: it >> happened once, but not any more - and I should find out what is missing... > >Are building out-of-tree? (Are your source tree and build tree separate dir?) >If so, did you try removing the entire build tree and try again ? Yes, it's out of tree. And also I did this removal and rebuild! This is exactly how I realized my problem: I had done once an "install build" that copied library files to the target - and everything looked find from then on. Until I did that exercise - and realized that nothing is copied any more! And because I could not find any plausible reason why this library copying did not happen any more, I gave this "install" business up for the moment... >May be there is probably some mixup with your install DESTINATION in your >install command. The problem is that I did not even change anything in that part of the project from the moment when it "accidentally" happened once... But sure, it is never pure magic: I MUST have done something "wrong"! >> My current workaround is indeed that I am trying to avoid the install >> step altogether and build a crazy construction with configure_file stuff >> in order to get the libraries to the right place - and I know pretty >> well that this is NOT the way how things should be done properly. But I >> am afraid I will be ready with this workaround way faster than I will >> understand what is going on during this miraculous "install" process! > >Provide us with a stripped down non-working example and we may dig into it. >Otherwise it is very difficult to guess what is happening in your particular >case. That's exactly my problem: I am working on a ParaView custom project, and then trying to "derive" another one from the first! So there is nothing to be easily "stripped down" - it is simply a monster project - and I am almost sure if I am going to write a simple dummy project, everything will just work fine... And this is why I was asking for a more thorough documentation that what you can find at Kitware where not the processes are explained, but just "what to do". So from what I see, if you start a cmake project from scratch, you can start with simple concepts and add towards more complex ones, with growing understanding. However, if you start to build on ParaView, you start in the middle of an already highly complex project setup, with little documentation than just examples - and the entire process feels a bit like learning C++ with only the source code of a C++ compiler at hand: certainly possible, but takes a horrible amount of time... ;-)
Re: [CMake] ?==?utf-8?q? Looking for an explanation: What exactly means "install" in cmake language?
Thanks to both you and J Decker: I would say that this is still the part that I understood! So basically the word "install" in cmake language could be replaced by "copy" more or less in common human language - right? But then, if it is about "installing" a "target", which is libraries in my case, I would expect the shared libraries to be copied - no? And this is exactly what does not happen - for no obvious reason! Because some days ago it even happened in my project ONCE - and then not any more. But debugging is not easy because since that moment I changed many things, and basically the reason for my question is that I have no clear idea what EXACTLY should happen if I put a install(TARGETS mylibrary) into my CMakeLists.txt. Well, like you explained, and like what I also thought I had understood: nothing should happen during the configure and generate runs of cmake, and also not during the "ninja all" build run, but only during the "ninja install". or else cmake --build . --target install (which in turn calls ninja in my case). Indeed I observed that it does a build for "all" first if the initial project is not up to date. But then it tells me that it is successfully "installing" mylibrary, but I see no shared library appearing in the install tree! Or rather: it happened once, but not any more - and I should find out what is missing... My current workaround is indeed that I am trying to avoid the install step altogether and build a crazy construction with configure_file stuff in order to get the libraries to the right place - and I know pretty well that this is NOT the way how things should be done properly. But I am afraid I will be ready with this workaround way faster than I will understand what is going on during this miraculous "install" process! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
[CMake] Looking for an explanation: What exactly means "install" in cmake language?
Constantly I am stumbling over the word "install" in the context of cmake
scripts - while it is pretty clear that the word cannot mean what nowadays
people would understand by that term! But even reading the docs forwards and
backwards, studying examples and some generic cmake tutorials I still do hot
have a PRECISE idea about what it is actually doing and what the purpose is.
Well, I can see everywhere HOW it is done - but it is sometimes an advantage if
you also know WHAT!
I know that this question is probably so stupid that I do not really expect
anybody to answer it here in the mailing list, but maybe somebody can point me
to a resource that explains it in a language that a "mere mortal programmer"
can follow?
So far I have a certain kind of understanding, and sometimes it looks like this
is correct, but then again I have my certain doubts. I am using
install(TARGETS), install(FILES) and install(EXPORT) so far, and the way I am
doing it I mostly picked from some general intros and tutorials. And from what
I understand, this is what I expect to happen:
install(FILES): some files are copied from some location in the build tree to
some installation location
install(EXPORT): some cmake script is written that a "derived" project can call
(through find_package) in order to get knowledge about my project
install(TARGET): not really an idea what should happen: also some copying from
build tree to installation tree I suppose
Now I also learned that the install step does not happen during a normal build
"all" - like "ninja all", but requires an extra "ninja install" step. And also
I saw that you can adapt the target of the installation process like this in
your project - if you never ever expect the build to be "installed" anywhere
else:
set(CMAKE_INSTALL_PREFIX ${CMAKE_CURRENT_BINARY_DIR}/../install CACHE PATH ""
FORCE)
With this I would expect to generate an install folder in parallel to the bin,
lib64 and other folders in the build tree, collecting there all the "products"
of the build for further processing by a derived project.
But what I see is actually - almost nothing!
Well, the install(FILES) actually copies a file, and the install(EXPORT) indeed
generates a cmake script, but from the install(TARGET) I see no effect: the
install folder remains completely empty! Still I see in the log many things
like "Installing: /.../install/bin/" - but I never find then
in that indicated location. But yes, it said "installing", not
"copying" - so I am back to my initial question: what the hell is "installing"
in cmake language?
So basically my problem is: I cannot judge whether my script is working because
I simply do not know what SHOULD be the effect of install(TARGET)!
Ah yes, my build tree is after a "normal build" ("all", not "install") full of
cmake_install.cmake files that would probably have something to do with that
"installation" process, but what? Am I supposed to call them on any occasion or
are they supposed to be called automatically at some moment?
Finally, I managed to get also some find_package() working for my project. The
"heart" of this is a Config.cmake script that I am generating during
the project build, and which I can write in whatever way I want. For example, I
am reading everywhere that I am supposed to do an install(EXPORT) in order to
make that find_package() happen, but since I do not really understand what it
is supposed to do, and I also see that I can simply write that Config file in
such a way that it picks things from where the build process puts them, I do
not really see the point.
In other words: I tend to simply write config scripts for the import that rely
on the build tree and simply skip that install step - because getting this to
work is so difficult if you never know what is supposed to happen how and at
what stage of the process and under which conditions!
But then I see that others are still using the install() steps, so there is
probably still some meaning in it...
So IF such a thing exists, like a comprehensive explanation about what
"install" actually means and what it is supposed to do at what stage of the
process, I would be very happy and thankful!
Best regards,
Cornelis
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] ?==?utf-8?q? ?==?utf-8?q? ?= Debug logging of item
Thanks for the hint: This may indeed help for some situations!
But explicitly not in the most important case because it explicitly says "The
list does not include any Imported Targets or Alias Targets, but does include
Interface Libraries." Well, these would of course be the most important target
types - like after a find_package().
I conclude from your answer (and the previous one) that indeed the thing that I
am looking for does currently NOT exist! So I may try to launch it as a
"feature request" - because I cannot believe that I am the only one who gets
lost in this field.
On the other hand I can also not believe that it can be too difficult to
implement: The interpreter can always tell me if a target_link_libraries(...)
is referring to an "unknown target" - so why not have a function that simply
tells me which targets are known - including ALL possible targets?
I like many of the automatisms that CMake is offering, but like with all
automatisms: If things do not work as expected you need a way to find out what
the problem is - and plain guessing is only an option for really trivial cases!
But even there it is only second choice if the software could just as well tell
you exactly what the problem is...
Best regards,
Cornelis
Am Sonntag, September 22, 2019 21:46 CEST, Craig Scott
schrieb:
You may want to take a look at the BUILDSYSTEM_TARGETS directory property. It
might not be quite what you're looking for, but it might be close enough. I'm
not aware of any way to get a list of all defined properties on a given target
though. On Mon, Sep 23, 2019 at 12:47 AM Cornelis Bockemühl
wrote:
Hi Eric,
Thanks for the hint regarding dumping variables: That's good to know!
However, I was learning that working with CMake is in may ways a question of
adopting some "good practice", but it is not really being enforced by the
language. One of the things that are for me part of this good practice would be
to deal with targets and their dependencies, and properties. Which means a
certain degree of modularity in the sense that you can easily plug projects
together by just referring to targets, like by calling find_package().
But again: You will never easily know what a package is actually giving you -
without investing hours and days of code reading - and maybe not even then!
But calling some "dump_targets" function after "find_package" (or also before
and after - for comparison) would give you a chance to know the effect of
endless "code deserts" with one line of code.
And because this is so fundamental in my eyes, I still almost assume that also
for targets and properties there must be some function available - which I
simply have not found yet!??
Or else I would consider this an urgent feature request!
Best regards,
Cornelis
Am Freitag, September 20, 2019 15:07 CEST, Eric Doenges
schrieb:
I don't know about the targets, but you can get all variables currently defined
for a directory by reading the VARIABLES property, e.g.
get_property(_variables DIRECTORY "${CMAKE_SOURCE_DIR}" PROPERTY VARIABLES)
I use this to dump the variables into a file so I can see with which variable
settings my build directory was configured with.
With kind regards,
EricAm 20.09.19 um 14:49 schrieb Cornelis Bockemühl:
Right now I am fighting my way through large amounts of CMake code (actually
working on a ParaView custom application with many own plugins, views, domains,
property widgets etc. etc.), and it is sometimes really not easy not to lose
track completely! Sometimes I am happy to be back into complex C++ programming
- because I see much more logic in the entire thing. And it is of course no
news that CMake code is not famous for being easy to debug.
Anyway, I am dreaming of some "simple" features that would sometimes help a
lot, and it is all about "dumping" some kind of data. Actually this is for me
often also the favorite way to debug C++ code: just print out the values of
variables, arrays, etc. - e.g. if setting a breakpoint in the debugger is
difficult because you are interested only in the 928773th occurrence of a
certain piece of code (without even knowing that number...).
Accordingly in CMake code I am working a lot with the message() function - but
within that code the problem is often that you do not even know which variables
would be available at all!
Thus functions like would be really great to have:
“give me a list of all currently known targets”
“give me a list of all properties of a target”
“give me a list of all currently defined variables”
etc.
What I do not know is: Are this things that already exist - in which case I
would be happy if somebody could tell me how to find them! -, or are these
functions rather "feature requests"?
In fact I can hardly believe that I am the first with such kind of dreams, so
my hope is
Re: [CMake] ?==?utf-8?q? Debug logging of items
Hi Eric,
Thanks for the hint regarding dumping variables: That's good to know!
However, I was learning that working with CMake is in may ways a question of
adopting some "good practice", but it is not really being enforced by the
language. One of the things that are for me part of this good practice would be
to deal with targets and their dependencies, and properties. Which means a
certain degree of modularity in the sense that you can easily plug projects
together by just referring to targets, like by calling find_package().
But again: You will never easily know what a package is actually giving you -
without investing hours and days of code reading - and maybe not even then!
But calling some "dump_targets" function after "find_package" (or also before
and after - for comparison) would give you a chance to know the effect of
endless "code deserts" with one line of code.
And because this is so fundamental in my eyes, I still almost assume that also
for targets and properties there must be some function available - which I
simply have not found yet!??
Or else I would consider this an urgent feature request!
Best regards,
Cornelis
Am Freitag, September 20, 2019 15:07 CEST, Eric Doenges
schrieb:
I don't know about the targets, but you can get all variables currently defined
for a directory by reading the VARIABLES property, e.g.
get_property(_variables DIRECTORY "${CMAKE_SOURCE_DIR}" PROPERTY VARIABLES)
I use this to dump the variables into a file so I can see with which variable
settings my build directory was configured with.
With kind regards,
EricAm 20.09.19 um 14:49 schrieb Cornelis Bockemühl:
Right now I am fighting my way through large amounts of CMake code (actually
working on a ParaView custom application with many own plugins, views, domains,
property widgets etc. etc.), and it is sometimes really not easy not to lose
track completely! Sometimes I am happy to be back into complex C++ programming
- because I see much more logic in the entire thing. And it is of course no
news that CMake code is not famous for being easy to debug.
Anyway, I am dreaming of some "simple" features that would sometimes help a
lot, and it is all about "dumping" some kind of data. Actually this is for me
often also the favorite way to debug C++ code: just print out the values of
variables, arrays, etc. - e.g. if setting a breakpoint in the debugger is
difficult because you are interested only in the 928773th occurrence of a
certain piece of code (without even knowing that number...).
Accordingly in CMake code I am working a lot with the message() function - but
within that code the problem is often that you do not even know which variables
would be available at all!
Thus functions like would be really great to have:
“give me a list of all currently known targets”
“give me a list of all properties of a target”
“give me a list of all currently defined variables”
etc.
What I do not know is: Are this things that already exist - in which case I
would be happy if somebody could tell me how to find them! -, or are these
functions rather "feature requests"?
In fact I can hardly believe that I am the first with such kind of dreams, so
my hope is still that they already exist somewhere...--
Dr. Eric Dönges
Senior Software Engineer
MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com | Tel: +49 89 457 695-0 | www.mvtec.com
Find our privacy policy here.
Sign up for our MVTec Newsletter!
Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695
--
Cornelis Bockemühl
mail: corne...@bockemuehl.ch
phone: +41 79 644 9943
Basel, Switzerland
https://cobo.bockemuehl.ch
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
[CMake] Debug logging of items
Right now I am fighting my way through large amounts of CMake code (actually working on a ParaView custom application with many own plugins, views, domains, property widgets etc. etc.), and it is sometimes really not easy not to lose track completely! Sometimes I am happy to be back into complex C++ programming - because I see much more logic in the entire thing. And it is of course no news that CMake code is not famous for being easy to debug. Anyway, I am dreaming of some "simple" features that would sometimes help a lot, and it is all about "dumping" some kind of data. Actually this is for me often also the favorite way to debug C++ code: just print out the values of variables, arrays, etc. - e.g. if setting a breakpoint in the debugger is difficult because you are interested only in the 928773th occurrence of a certain piece of code (without even knowing that number...). Accordingly in CMake code I am working a lot with the message() function - but within that code the problem is often that you do not even know which variables would be available at all! Thus functions like would be really great to have: “give me a list of all currently known targets” “give me a list of all properties of a target” “give me a list of all currently defined variables” etc. What I do not know is: Are this things that already exist - in which case I would be happy if somebody could tell me how to find them! -, or are these functions rather "feature requests"? In fact I can hardly believe that I am the first with such kind of dreams, so my hope is still that they already exist somewhere... -- Cornelis Bockemühl mail: corne...@bockemuehl.ch phone: +41 79 644 9943 Basel, Switzerland https://cobo.bockemuehl.ch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] conditions and included subprojects
Thanks for your proposals! Actually my problem is basically that I want to keep up with some minimum good practice, but I am seeing myself throwing it over board constantly if I do not find a logical solution after one or two hours of struggling... Your second option is close to what I am currently implementing - basically just hard-code the option into the sub-project and let the user adapt the CMakeLists.txt before starting cmake. A bit "brute force", not nice, certainly not "good practice" - but works! However, what I imagine is rather like this - from a user perspective: - if the user goes into the main project with cmake-gui, he will see THAT_OPTION with a default value and of course the option to change it. In this case, the sub-project should be built without further bothering the user with options - just take it from the main project. The point is that the option will have an effect for both the main and the sub project, but it has to be the same in both. - if the user goes directly into the sub project with cmake-gui, he should also see THAT_OPTION, but now it would come from the CMakeLists.txt of the sub project. Again with a default value and the option to change it. My guess is that I would need an additional "flag" variable that tells the sub project whether it is now being built within the main project or standalone. Again not so nice, but besides the "brute force solution" (hardcoded) the only one that I can see to do it more nicely... Regards,Cornelis Am Montag, den 11.06.2018, 10:44 +0200 schrieb Andreas Naumann: > Dear Cornelis, > > > > your description looks to me like having a three valued option: ON, > OFF, UNDEFINED. But an option in cmake language has only two values: > ON or OFF. > > To solve your problem with the connection between your sub-project > and the main project, you should forget about the main project and > concentrate on the sub project only. Than, you have two > possibilities: > > 1) Keep the three state variable "THAT_OPTION". Set it to > undefined at the very beginning and check later with if(DEFINED > THAT_OPTION) With this variant, you can handle the "I forgot to > set it"-case. But your user will not see it as an option in the cmake > gui. Your main project will set it, as desired. > > 2) Use an initial value for the option. Now, it is always > defined, there is no need to check for the source. It is the > responsibility of the user to set the option appropriately. > > > > I think, the second version is the easiest way. > > > > Regards, > > Andreas > > > > Gesendet: Montag, 11. Juni 2018 um 10:20 Uhr > > Von: "Cornelis Bockemühl" > > An: cmake@cmake.org > > Betreff: [CMake] conditions and included subprojects > > > Dear CMake users, > > > > > > Maybe my question is trivial for most, but still I do not find an > answer on my own! > > > > > > If you have a project and some sub-project (or module or whatever the > jargon is) that are both managed with CMake, they should be in > separate directories (directory trees), and each of them have a > CMakeLists.txt in the root directory, where the sub-project is > "included" into the main project with an ADD_DIRECTORY() etc. So far > so clear. > > > > > > But then I learned that it is good practice to ensure that the sub- > project would also be "buildable" with cmake separately. My problem > is about how to pass options from the main to the sub project in such > a way that this is working properly, i.e.: > > > > > > - if the sub project is part of the main project it would simply take > over the option from the main project level > > > - but if the sub project is being built standalone, the option is not > defined and should be set e.g. in cmake-gui > > > > > > If I write now in the sub project > > > > > > IF(THAT_OPTION) > > > ... > > > > > > this will be true if THAT_OPTION was set to ON in the main project. > So far so good. But the expression is now so "clever" that it cannot > distinguish between THAT_OPTION being set to OFF in the main project, > or THAT_OPTION not being defined at all - like in a standalone build! > > > > > > One way would be to have an additional option or variable > BUILDING_MAINPROJECT which is set to ON or TRUE in the main project > and can be checked. However, I have so far not seen any > CMakeLists.txt with such a code, so ... what are the experts doing in > such a case? > > > > > > Thanks and regards, > > > Cornelis > &g
[CMake] conditions and included subprojects
Dear CMake users, Maybe my question is trivial for most, but still I do not find an answer on my own! If you have a project and some sub-project (or module or whatever the jargon is) that are both managed with CMake, they should be in separate directories (directory trees), and each of them have a CMakeLists.txt in the root directory, where the sub-project is "included" into the main project with an ADD_DIRECTORY() etc. So far so clear. But then I learned that it is good practice to ensure that the sub- project would also be "buildable" with cmake separately. My problem is about how to pass options from the main to the sub project in such a way that this is working properly, i.e.: - if the sub project is part of the main project it would simply take over the option from the main project level - but if the sub project is being built standalone, the option is not defined and should be set e.g. in cmake-gui If I write now in the sub project IF(THAT_OPTION) ... this will be true if THAT_OPTION was set to ON in the main project. So far so good. But the expression is now so "clever" that it cannot distinguish between THAT_OPTION being set to OFF in the main project, or THAT_OPTION not being defined at all - like in a standalone build! One way would be to have an additional option or variable BUILDING_MAINPROJECT which is set to ON or TRUE in the main project and can be checked. However, I have so far not seen any CMakeLists.txt with such a code, so ... what are the experts doing in such a case? Thanks and regards, Cornelis-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake analogue - syncProj visual studio generation tool
Hello Tarmo, Reading this on the CMake mailing list I am first of all asking myself: Why should I go for such a certainly nice alternative if I already have CMake? At the same time I think that _answering_ this question is probably not a subject that fits into the CMake mailing list because it is obviously for CMake issues, not ads for alternatives. So in this sense my question is rhetoric only... ;-) Providing a link to further documentation (like you are doing!) is certainly enough here - and I can see that there is the one or other function that CMake does not offer. I am not asking _why_ you are writing this at all! If you are doing this in your free time I understand 100% the fun it is to re-invent the one or other wheel: I did that many times in the past, so I assume that I understand pretty well... On the other hand: Just think about the fact that CMake is indeed Open Source! It means not more and not less than that nobody is constrained to the functionality that some "gods" are offering (like it is the case with the MS Visual Studio - mostly), but you would be able to add the things that you are missing and build on the many available features that others have implemented so far - and which you will have to rewrite for your project from scratch. In other words: Standing on the shoulders of a giant gives you a phantastic view and lets you feel like you are a giant yourself! ;-) So in short: Thanks for the free offer, but I don't need it because I have CMake! Regards, Cornelis Am Samstag, den 31.03.2018, 08:19 + schrieb Tarmo Pikaro via CMake: > Hi ! > > > > On my own free time I've managed to create tool similar to cmake - command line tool called syncProj. > > > > > Currently syncProj is aiming also for portability, but it currently has narrower list of supported platforms - supported platforms are at this moment only Windows and Android, but > only Visual studio based. > > > > Where cmake is using special kind of language, syncProj uses C# programming language as a base, and because of this allows full support for > > syncProj C# script code syntax highlighting, intellisense and full debug support. > > Documentation: > > https://docs.google.com/document/d/1C1YrbFUVpTBXajbtrC62aXru2om6dy5rC lyknBj5zHU/edit# > > > Source code: > https://sourceforge.net/projects/syncproj > > > syncProj is something that was just born on the way of making another project, and I suspect that it's far from supporting > > all visual studio project parameters and configurations, but it provides solid code base for future development. > > > So if you're familiar with C# or not familiar, but willing to learn, feel free to contact me, I can guide in syncProj code base > and teach you how to improve syncProj. > > > Currently syncProj supports C++, but not C#, as a platform base runs only on Windows, and limited to Windows / Android platforms. > > > > What I have checked through Visual studio even currently start to support Linux based platforms, so if you want to or need that platform, > I can guide you through how to add that support into syncProj. > > > Current code coverage level is 83.23% and I plan to increase that value with each future change. > > --- Future considerations -- > > > > Currently I see syncProj as intermediate solution or a tool - I think in future syncProj could actually become built-in into Visual studio itself, > > > as base class hierachy - something similar Microsoft guys are trying to achieve right now by integrating cmake initial support into Visual studio. > > > > cmake scripting language dialect is more difficult to learn than C#, but of course ideal world would be if C++ project would be configured > using C++ "script" syntax. > > > But at the moment C# allows on-fly compiling of C# code, but not C++. I think that through making C++ modules possible + > > > allowing to compile C++ immediately - this would permit to make new variation of syncProj, which would be coded in C++ fully, but this is something > > to consider later on, after C++ modules starts working in full scale on multiple compilers. > > > --Have a nice day! Tarmo. > > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Parallel build setup question
Just to close this thread: Also the ninja tipp turned out to be a very good one! I did the same full built (clear - rebuild) with ninja instead of make -j4 and times were more or less comparable: from initially 23 minutes down to 13-14 with make, and 12-13 with ninja. However, what is much more helpful in practical programming work is the fact that if I change only one or two files, ninja "knows" this instantaneously, i.e. no perceivable overhead to find out about outdated files, while make still takes maybe half a minute or such for checking. And since this is a very common case during development I decided to stay with the QtCreator - CMake - ninja "team of tools"! Regards, Cornelis Am Samstag, den 17.02.2018, 08:06 +0100 schrieb Cornelis Bockemühl: > Thanks also for this hint: I will give it a try! > > Regards, Cornelis > > Am Freitag, den 16.02.2018, 21:35 +0300 schrieb Konstantin Tokarev: > > > > 16.02.2018, 21:32, "Cornelis Bockemühl" <corne...@bockemuehl.ch>: > > > Thanks - that did the trick! > > > > > > > > > > > > > > > And indeed by entering -j4 in the "Tool arguments" > > > > > > > > > > > > field, the build command changes "magically" into "cmake --build . --target all -- -j4" - with the "--" to pass the argument further to gmake. > > > > > > > > > > > > > > > > > > > > > Actually compile time of my project after a > > > > > > > > > > > > > > > > > > "clean" went down from 23 to 14 min, thus reduction factor 1.6 with 4 processors: I tend to attribute the diffference to "almost 4" to the nature of my project where gmake seems not to see too many opportunities for parallel processing. Maybe it works always module by module, or whatever. > > > > > > Anyway, my question is answered - thanks again! > > > > > > Note that if you used Ninja generator, it would use all cores by default. > > > > > > > > Regards, > > > Cornelis > > > > > > > > > Am Freitag, den 16.02.2018, 20:25 +0300 schrieb Konstantin Tokarev: > > > > > > > > 16.02.2018, 20:20, "Cornelis Bockemühl" <corne...@bockemuehl.ch >: > > > > > > > > > > > > > > > Thanks for your hints! And you are right: it is > > > > > > > > > > > > > > > still interesting to know how QtCreator is actually invoking and using cmake. > > > > > > > > > > > > You should go to project settings and change cmake --build arguments there > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is the beginning of a > > > > > > > > > > > > > > > > > > > > > > > > > log that the QtCreator was generating during a build. Actually with two modules where nothing had to be done, but still showing how cmake and gmake are being invoked - and all a bit above my understanding of the two tools: > > > > > > > > > > === > > > > > > > > > > > > > > > /usr/bin/cmake -H/Sources/GitLinux/RMT -B/BinariesLinux/RMT/Debug --check-build-system CMakeFiles/Makefile.cmake 0 > > > > > > > > > > > > > > > /usr/bin/cmake -E cmake_progress_start /BinariesLinux/RMT/Debug/CMakeFiles /BinariesLinux/RMT/Debug/CMakeFiles/progress.marks > > > > > /usr/bin/gmake -f CMakeFiles/Makefile2 all > > > > > gmake[1]: Entering directory '/BinariesLinux/RMT/Debug' > > > > > > > > > > /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make CMakeFiles/FirstModule.dir/depend > > > > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug' > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > cd > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /BinariesLinux/RMT/Debug > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > && /usr/bin/cmake > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -E cmake_depends "Unix Makefiles&
Re: [CMake] Parallel build setup question
Thanks also for this hint: I will give it a try! Regards, Cornelis Am Freitag, den 16.02.2018, 21:35 +0300 schrieb Konstantin Tokarev: > > > 16.02.2018, 21:32, "Cornelis Bockemühl" <corne...@bockemuehl.ch>: > > Thanks - that did the trick! > > > > > > > > And indeed by entering -j4 in the "Tool arguments" field, the build command changes "magically" into "cmake --build . --target all -- -j4" - with the "--" to pass the argument further to gmake. > > > > > > > > > > > > > > Actually compile time of my project after a "clean" > > > > > > > > > > > > went down from 23 to 14 min, thus reduction factor 1.6 with 4 processors: I tend to attribute the diffference to "almost 4" to the nature of my project where gmake seems not to see too many opportunities for parallel processing. Maybe it works always module by module, or whatever. > > > > Anyway, my question is answered - thanks again! > > > Note that if you used Ninja generator, it would use all cores by default. > > > > > Regards, > > Cornelis > > > > Am Freitag, den 16.02.2018, 20:25 +0300 schrieb Konstantin Tokarev: > > > > > > 16.02.2018, 20:20, "Cornelis Bockemühl" <corne...@bockemuehl.ch>: > > > > > > > > > > > > Thanks for your hints! And you are right: it is still interesting to know how QtCreator is actually invoking and using cmake. > > > > > > > > > You should go to project settings and change cmake --build arguments there > > > > > > > > > > > > > > > > > > > > > > > This is the beginning of a log that the > > > > > > > > > > > > > > > > > > > > QtCreator was generating during a build. Actually with two modules where nothing had to be done, but still showing how cmake and gmake are being invoked - and all a bit above my understanding of the two tools: > > > > > > > > === > > > > > > > > > > > > /usr/bin/cmake -H/Sources/GitLinux/RMT -B/BinariesLinux/RMT/Debug --check-build-system CMakeFiles/Makefile.cmake 0 > > > > > > > > > > > > /usr/bin/cmake -E cmake_progress_start /BinariesLinux/RMT/Debug/CMakeFiles /BinariesLinux/RMT/Debug/CMakeFiles/progress.marks > > > > /usr/bin/gmake -f CMakeFiles/Makefile2 all > > > > gmake[1]: Entering directory '/BinariesLinux/RMT/Debug' > > > > > > > > /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make CMakeFiles/FirstModule.dir/depend > > > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug' > > > > > > > > > > > > > > > > > > > > cd /BinariesLinux/RMT/Debug && > > > > > > > > > > > > > > > > > > > > /usr/bin/cmake -E cmake_depends "Unix Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug/CMakeFiles/FirstModule.dir/DependInfo. cmake --color= > > > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug' > > > > > > > > /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make CMakeFiles/FirstModule.dir/build > > > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug' > > > > > > > > gmake[2]: Nothing to be done for 'CMakeFiles/FirstModule.dir/build'. > > > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug' > > > > [ 3%] Built target FirstModule > > > > > > > > /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make CMakeFiles/SecondModule.dir/depend > > > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug' > > > > > > > > > > > > > > > > > > > > cd /BinariesLinux/RMT/Debug && > > > > > > > > > > > > > > > > > > > > /usr/bin/cmake -E cmake_depends "Un
Re: [CMake] Parallel build setup question
Thanks - that did the trick! And indeed by entering -j4 in the "Tool arguments" field, the build command changes "magically" into "cmake --build . --target all -- -j4" - with the "--" to pass the argument further to gmake. Actually compile time of my project after a "clean" went down from 23 to 14 min, thus reduction factor 1.6 with 4 processors: I tend to attribute the diffference to "almost 4" to the nature of my project where gmake seems not to see too many opportunities for parallel processing. Maybe it works always module by module, or whatever. Anyway, my question is answered - thanks again! Regards, Cornelis Am Freitag, den 16.02.2018, 20:25 +0300 schrieb Konstantin Tokarev: > > > > 16.02.2018, 20:20, "Cornelis Bockemühl" <corne...@bockemuehl.ch>: > > > > Thanks for your hints! And you are right: it is still interesting to know how QtCreator is actually invoking and using cmake. > > You should go to project settings and change cmake --build arguments there > > > > > > > > > > > This is the beginning of a log that the QtCreator was generating during a build. Actually with two modules where nothing had to be done, but still showing how cmake and gmake are being invoked - and all a bit above my understanding of the two tools: > > > > === > > > > /usr/bin/cmake -H/Sources/GitLinux/RMT -B/BinariesLinux/RMT/Debug --check-build-system CMakeFiles/Makefile.cmake 0 > > > > > > /usr/bin/cmake -E cmake_progress_start /BinariesLinux/RMT/Debug/CMakeFiles /BinariesLinux/RMT/Debug/CMakeFiles/progress.marks > > /usr/bin/gmake -f CMakeFiles/Makefile2 all > > gmake[1]: Entering directory '/BinariesLinux/RMT/Debug' > > > > /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make CMakeFiles/FirstModule.dir/depend > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug' > > > > > > > > > > cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E > > > > > > > > > > cmake_depends "Unix Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug/CMakeFiles/FirstModule.dir/DependInfo.cmak e --color= > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug' > > > > /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make CMakeFiles/FirstModule.dir/build > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug' > > > > gmake[2]: Nothing to be done for 'CMakeFiles/FirstModule.dir/build'. > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug' > > [ 3%] Built target FirstModule > > > > /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make CMakeFiles/SecondModule.dir/depend > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug' > > > > > > > > > > cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E > > > > > > > > > > cmake_depends "Unix Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug/CMakeFiles/SecondModule.dir/DependInfo.cma ke --color= > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug' > > > > /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make CMakeFiles/SecondModule.dir/build > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug' > > > > gmake[2]: Nothing to be done for 'CMakeFiles/SecondModule.dir/build'. > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug' > > [ 6%] Built target SecondModule > > ... > > === > > > > > > > > For example I do not really understand all the parameters that are passed to cmake - and I do not find them in the documentation either (like -H, -B or --check-build-system... > > > > Regards, > > Cornelis > > > > Am Freitag, den 16.02.2018, 08:59 -0800 schrieb Michael Ellery: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don’t know anything about QTCreator, but the question really boils down to how to get your IDE
Re: [CMake] Parallel build setup question
Thanks for your hints! And you are right: it is still interesting to know how QtCreator is actually invoking and using cmake. This is the beginning of a log that the QtCreator was generating during a build. Actually with two modules where nothing had to be done, but still showing how cmake and gmake are being invoked - and all a bit above my understanding of the two tools: === /usr/bin/cmake -H/Sources/GitLinux/RMT -B/BinariesLinux/RMT/Debug -- check-build-system CMakeFiles/Makefile.cmake 0 /usr/bin/cmake -E cmake_progress_start /BinariesLinux/RMT/Debug/CMakeFiles /BinariesLinux/RMT/Debug/CMakeFiles/progress.marks /usr/bin/gmake -f CMakeFiles/Makefile2 all gmake[1]: Entering directory '/BinariesLinux/RMT/Debug' /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make CMakeFiles/FirstModule.dir/depend gmake[2]: Entering directory '/BinariesLinux/RMT/Debug' cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug/CMakeFiles/FirstModule.dir/DependInfo.cmake -- color= gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug' /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make CMakeFiles/FirstModule.dir/build gmake[2]: Entering directory '/BinariesLinux/RMT/Debug' gmake[2]: Nothing to be done for 'CMakeFiles/FirstModule.dir/build'. gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug' [ 3%] Built target FirstModule /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make CMakeFiles/SecondModule.dir/depend gmake[2]: Entering directory '/BinariesLinux/RMT/Debug' cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug/CMakeFiles/SecondModule.dir/DependInfo.cmake --color= gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug' /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make CMakeFiles/SecondModule.dir/build gmake[2]: Entering directory '/BinariesLinux/RMT/Debug' gmake[2]: Nothing to be done for 'CMakeFiles/SecondModule.dir/build'. gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug' [ 6%] Built target SecondModule ... === For example I do not really understand all the parameters that are passed to cmake - and I do not find them in the documentation either (like -H, -B or --check-build-system... Regards, Cornelis Am Freitag, den 16.02.2018, 08:59 -0800 schrieb Michael Ellery: > > > > > > > > > > > > > > I don’t know anything about QTCreator, but the > > > > > > > > > > > > > > question really boils down to how to get your IDE to pass extra args to the build tool - it’s not really a cmake issue except to the extent that CMake can be used to invoke the build step (after it has been used to generate the build). It sounds like QT uses “cmake --build” to do the build phase (which makes sense), so you just need to add your “-j N” argument to the build step invocation. If you believe this: https://doc.qt.io/qt creator/creator-build-settings.html, then it sounds like maybe “Tool Arguments” is what you want (see “CMake Build Steps”) ? BTW, the way I do this myself (since I don’t use an IDE) is something like “cmake --build . -- -j 8” where the double dash stops shell argument processing and effectively passes everything else on to the build tool that cmake ultimately invokes (e.g. make or ninja or msbuild, etc.) > > HTH, > Mike > > > > > On Feb 16, 2018, at 8:31 AM, Cornelis Bockemühl <cornelis@bockemueh l.ch> wrote: > > > > Hello, > > > > > > > > Somehow I seem to miss some crucial point regarding setup for parallel build with CMake, so I would be happy if somebody can push me the last few millimeters to hit my target! > > > > > > My configuration is on OpenSuse Linux (Leap - 64-bit), working with QtCreator and CMake, using the "make" configuration. > > > > > > > > > > I learned from "the internet" that actually I would have to > > > > > > > > pass a -jN option to make or gmake (with N being the max number of processors I want to use). Or even more elegant: go for a -lN option to somehow balance the load. Sounds good! > > > > > > > > > > > > > > But what I do not see is how to pass these nice options > > > > > > > > > > > > to make through CMake and QtCreator! One attempt was to specify CMAKE_CXX_FLAGS=-j4 or the like because some comment "in the internet" seemed to suggest this. However, like I already feared: this passes the option to the compiler call - and that is the wrong addr
[CMake] Parallel build setup question
Hello, Somehow I seem to miss some crucial point regarding setup for parallel build with CMake, so I would be happy if somebody can push me the last few millimeters to hit my target! My configuration is on OpenSuse Linux (Leap - 64-bit), working with QtCreator and CMake, using the "make" configuration. I learned from "the internet" that actually I would have to pass a -jN option to make or gmake (with N being the max number of processors I want to use). Or even more elegant: go for a -lN option to somehow balance the load. Sounds good! But what I do not see is how to pass these nice options to make through CMake and QtCreator! One attempt was to specify CMAKE_CXX_FLAGS=-j4 or the like because some comment "in the internet" seemed to suggest this. However, like I already feared: this passes the option to the compiler call - and that is the wrong address for it, so I get an error message. Basically I think that it is 99% a CMake question and maximum 1% a QtCreator problem, so I am asking this question here. And now I am stuck - if not some friendly and knowing person can help me out of this! Thanks for any helpful hint! Cornelis-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Strange error with brand new CMake 4.10.0 - SOLVED
What a shame! Actually that error message comes from my own CMakeLists.txt file - where I had so far only configured some settings for Linux and not yet for MSVC... This is indeed not any more the MT problem, but simply my own - so please forget about my previous posting! Regards, Cornelis Am Mittwoch, den 22.11.2017, 09:56 +0100 schrieb Cornelis Bockemühl: > > > > > Yesterday I had a problem with the CMake release candidate 4 for the version 4.10.0 on Windows with MSVC 2015, and I realized by reading the CMakeOutput.log that testing the Manifest Tool (MT) was failing. And with a little Google I got the impression that this is now fixed with the final release: > > > https://gitlab.kitware.com/cmake/cmake/commit/2201ecec44adcc490c7481a 52a88d6543bc5dd7b > > > > > > Now today seeing on the cmake.org website that the version 4.10.0 is out I immediately downloaded and installed it. However the result is a bit disappointing: Indeed the error message has gone from the CMakeOutput.log file - but the Configure run still fails with the same message: > > CMake Error at CMakeLists.txt:32 (message): > MSVS not properly configured yet! > > Now I am lost because I really do not know where to look further! > > > > For the very moment, and in order to have a quick solution, I will now probably simply downgrade to the previous version 3.9, but still I wanted to report this problem to the experts! > > Regards, Cornelis -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Strange error with brand new CMake 4.10.0
Yesterday I had a problem with the CMake release candidate 4 for the version 4.10.0 on Windows with MSVC 2015, and I realized by reading the CMakeOutput.log that testing the Manifest Tool (MT) was failing. And with a little Google I got the impression that this is now fixed with the final release: https://gitlab.kitware.com/cmake/cmake/commit/2201ecec44adcc490c7481a52 a88d6543bc5dd7b Now today seeing on the cmake.org website that the version 4.10.0 is out I immediately downloaded and installed it. However the result is a bit disappointing: Indeed the error message has gone from the CMakeOutput.log file - but the Configure run still fails with the same message: CMake Error at CMakeLists.txt:32 (message): MSVS not properly configured yet! Now I am lost because I really do not know where to look further! For the very moment, and in order to have a quick solution, I will now probably simply downgrade to the previous version 3.9, but still I wanted to report this problem to the experts! Regards, Cornelis-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] find_library not finding libraries - why?
Thanks - that was it! Now CMake is happy - just a question of
seconds...
Regarcs, Cornelis
Am Donnerstag, den 09.11.2017, 09:30 + schrieb CHEVRIER, Marc:
>
>
> > The problem is on NAMES argument. You have to specify library names
without prefix. So
> Clp must be used rather than libClp.
> FIND_LIBRARY(CLP_LIBRARY NAMES
> Clp PATHS ${CLP_LIB} NO_DEFAULT_PATH)
>
>
>
>
>
>
> > > > From: CMake on behalf of "cornelis@bockemue
hl.ch"
>
> Date: Thursday 9 November 2017 at 00:09
>
> > > To: "cmake@cmake.org"
>
> Subject: [CMake] find_library not finding libraries - why?
>
>
>
>
>
>
> In a CMakeLists.txt I have the following lines of code:
>
>
>
> # with this the user will be asked for a path that has then
>
> # lib64 other subdirectories that are specified below
>
> FIND_PATH(CLP_DIR libClp)
>
>
>
> SET(CLP_LIB ${CLP_DIR}/lib64)
>
>
>
> # after the user specified CLP_DIR this shows what is expected:
>
> # the full path to the libraries, but...
>
> message(AUTHOR_WARNING ${CLP_LIB})
>
>
>
> > # with the following I think I cannot indicate more clearly where the
libraries actually are:
>
> > FIND_LIBRARY(CLP_LIBRARY NAMES libClp PATHS ${CLP_LIB}
NO_DEFAULT_PATH)
>
> > FIND_LIBRARY(COINUTILS_LIBRARY NAMES libCoinUtils PATHS ${CLP_LIB}
NO_DEFAULT_PATH)
>
> > FIND_LIBRARY(OSI_LIBRARY NAMES libOsi PATHS ${CLP_LIB}
NO_DEFAULT_PATH)
>
> > FIND_LIBRARY(OSICLP_LIBRARY NAMES libOsiClp PATHS ${CLP_LIB}
NO_DEFAULT_PATH)
>
>
>
> # ...here everything comes as -NOTFOUND
>
> message(AUTHOR_WARNING ${CLP_LIBRARY})
>
> message(AUTHOR_WARNING ${COINUTILS_LIBRARY})
>
> message(AUTHOR_WARNING ${OSI_LIBRARY})
>
> message(AUTHOR_WARNING ${OSICLP_LIBRARY})
>
>
>
> A dir for the indicated directory shows the following files:
>
>
>
> -rwxrwxrwx 1 cornelis users 907 8. Nov 18:37 libClp.la
>
> > lrwxrwxrwx 1 cornelis users 42 8. Nov 18:37 libClp.so ->
libClp.so.1.13.11
>
> > lrwxrwxrwx 1 cornelis users 42 8. Nov 18:37 libClp.so.1 ->
libClp.so.1.13.11
>
> -rwxrwxrwx 1 cornelis users 1887336 8. Nov 18:37 libClp.so.1.13.11
>
> -rwxrwxrwx 1 cornelis users 1010 8. Nov 18:37 libClpSolver.la
>
> > lrwxrwxrwx 1 cornelis users 54 8. Nov 18:37 libClpSolver.so ->
libClpSolver.so.1.13.11
>
> > lrwxrwxrwx 1 cornelis users 54 8. Nov 18:37 libClpSolver.so.1
-> libClpSolver.so.1.13.11
>
> > -rwxrwxrwx 1 cornelis users 415224 8. Nov 18:37
libClpSolver.so.1.13.11
>
> -rwxrwxrwx 1 cornelis users 870 8. Nov 18:37 libCoinUtils.la
>
> > lrwxrwxrwx 1 cornelis users 54 8. Nov 18:37 libCoinUtils.so ->
libCoinUtils.so.3.10.14
>
> > lrwxrwxrwx 1 cornelis users 54 8. Nov 18:37 libCoinUtils.so.3
-> libCoinUtils.so.3.10.14
>
> > -rwxrwxrwx 1 cornelis users 1416632 8. Nov 18:37
libCoinUtils.so.3.10.14
>
> -rwxrwxrwx 1 cornelis users 1059 8. Nov 18:37 libOsiClp.la
>
> > lrwxrwxrwx 1 cornelis users 48 8. Nov 18:37 libOsiClp.so ->
libOsiClp.so.1.13.11
>
> > lrwxrwxrwx 1 cornelis users 48 8. Nov 18:37 libOsiClp.so.1 ->
libOsiClp.so.1.13.11
>
> > -rwxrwxrwx 1 cornelis users 350080 8. Nov 18:37
libOsiClp.so.1.13.11
>
> > -rwxrwxrwx 1 cornelis users 1038 8. Nov 18:37
libOsiCommonTests.la
>
> > lrwxrwxrwx 1 cornelis users 62 8. Nov 18:37
libOsiCommonTests.so -> libOsiCommonTests.so.1.12.9
>
> > lrwxrwxrwx 1 cornelis users 62 8. Nov 18:37
libOsiCommonTests.so.1 -> libOsiCommonTests.so.1.12.9
>
> > -rwxrwxrwx 1 cornelis users 619392 8. Nov 18:37
libOsiCommonTests.so.1.12.9
>
> -rwxrwxrwx 1 cornelis users 905 8. Nov 18:37 libOsi.la
>
> > lrwxrwxrwx 1 cornelis users 40 8. Nov 18:37 libOsi.so ->
libOsi.so.1.12.9
>
> > lrwxrwxrwx 1 cornelis users 40 8. Nov 18:37 libOsi.so.1 ->
libOsi.so.1.12.9
>
> -rwxrwxrwx 1 cornelis users 400776 8. Nov 18:37 libOsi.so.1.12.9
>
> drwxrwxrwx 1 cornelis users 4096 8. Nov 18:37 pkgconfig
>
>
>
> so the libraries are obviously there!
>
>
>
> Questions:
>
> What am I doing wrong?
>
> What did I possibly misunderstand regarding the find_library command?
>
>
>
> Thanks for any helpful hints!
>
> Cornelis
>
>
>
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
