n 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
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 see
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:
inst
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
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 service
> 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 "ins
>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
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
ca
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
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
Y 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 o
er "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
--
Powe
> 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.
>
>
>
>
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
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
ase 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,
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" :
> > Thanks - that did the trick!
> >
> > > > > > And indeed b
ule 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" :
> > > > Thanks for your hints! And you are righ
vocation. 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
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" configur
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.
An
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:
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.
> F
23 matches
Mail list logo