/path/to/libpng.so automatic conversion to -lpng ?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

/path/to/libpng.so automatic conversion to -lpng ?

René J. V.  Bertin
Hi,

I have a target_link_libraries command that uses ${PNG_LIBRARIES} and thus *should* add something like `/path/to/libpng.so /path/to/libz.so` to the linker command. Instead, I am getting a linker command line that has `-lpng -lz`, which fails for me because the `/path/to` in question isn't on the standard library search path.

Is there a cmake feature that does this automatic conversion, and if so how can I turn it off?

Thanks,
René
--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

Andreas Naumann
Dear Rene,

cmake instrospects your compiler and asks for system directories. Only
these system directories will be removed and the corresponding libraries
will be linked by -l<...>. So, you should check your compiler and the
environment. I had several problems years ago with the environment
variable LIBRARY_PATH, which leads to such a behavior.

Regards,
Andreas
Am 12.07.2017 um 13:38 schrieb René J.V. Bertin:
> Hi,
>
> I have a target_link_libraries command that uses ${PNG_LIBRARIES} and thus *should* add something like `/path/to/libpng.so /path/to/libz.so` to the linker command. Instead, I am getting a linker command line that has `-lpng -lz`, which fails for me because the `/path/to` in question isn't on the standard library search path.
>
> Is there a cmake feature that does this automatic conversion, and if so how can I turn it off?
>
> Thanks,
> René

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

René J. V.  Bertin
Andreas Naumann wrote:

> cmake instrospects your compiler and asks for system directories. Only
> these system directories will be removed and the corresponding libraries
> will be linked by -l<...>. So, you should check your compiler and the
> environment. I had several problems years ago with the environment
> variable LIBRARY_PATH, which leads to such a behavior.

Hello Andreas,

Aha, I indeed have LIBRARY_PATH=/opt/local/lib set (by the build scripts I use).
From what I understand, that variable allows you to specify a set of -L
directories via an env. variable (other than LDFLAGS).

It seems that clang handles that variable in a somewhat different manner than
GCC does. Even in a very simple call on the commandline (including the -v
option) I see it adds -L/opt/local/lib AFTER the user-supplied libraries, where
GCC puts it before the 1st -l option.

R.


--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

René J. V.  Bertin
In reply to this post by Andreas Naumann
FWIW, I do question this rewriting feature, because it clearly can go wrong.

I'd argue that programmers (or build script/cmake modules/...) usually have good
reason when they give the absolute path to a library: making darn sure it's
indeed that one that gets linked.

While I agree that replacing a full path with the -lfoo notation makes the final
command shorter and thus more readable it can also introduce subtle bugs. The
fact that a library can be found by the linker because it's on the search path
doesn't mean that the linker will find the right, intended library. In my case I
could get the correct linking by just adding -L/opt/local/lib, but what if for
some reason I had wanted to include the system libpng, i.e. if PNG_LIBRARIES had
pointed to /usr/lib/libpng.so?

I hope this is not such a corner case that Kitware haven't foreseen it and
implemented a way to deactivate the rewriting?

R.

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

Rolf Eike Beer
In reply to this post by René J. V. Bertin
Am Mittwoch, 12. Juli 2017, 18:31:56 schrieb René J. V. Bertin:

> Andreas Naumann wrote:
> > cmake instrospects your compiler and asks for system directories. Only
> > these system directories will be removed and the corresponding libraries
> > will be linked by -l<...>. So, you should check your compiler and the
> > environment. I had several problems years ago with the environment
> > variable LIBRARY_PATH, which leads to such a behavior.
>
> Hello Andreas,
>
> Aha, I indeed have LIBRARY_PATH=/opt/local/lib set (by the build scripts I
> use). From what I understand, that variable allows you to specify a set of
> -L directories via an env. variable (other than LDFLAGS).
>
> It seems that clang handles that variable in a somewhat different manner
> than GCC does. Even in a very simple call on the commandline (including the
> -v option) I see it adds -L/opt/local/lib AFTER the user-supplied
> libraries, where GCC puts it before the 1st -l option.
Welcome to the work of link_directories(). This is exactly the reason to avoid
it: it always causes trouble.

Eike
--

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

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

René J. V.  Bertin
Rolf Eike Beer wrote:

>> It seems that clang handles that variable in a somewhat different manner
>> than GCC does. Even in a very simple call on the commandline (including the
>> -v option) I see it adds -L/opt/local/lib AFTER the user-supplied
>> libraries, where GCC puts it before the 1st -l option.
>
> Welcome to the work of link_directories(). This is exactly the reason to avoid
> it: it always causes trouble.

digikam (that's the project we're talking about) doesn't use neither that nor
target_link_directories. And if CMake simply used the libraries as found and
specified in the target_link_libraries() call I wouldn't have run into problems
either.

I did raise a flag on the clang ML though. But whether it's a clang bug or
feature the fact remains that ideally one should be able to tell cmake exactly
what to do, without it trying to outguess the operator.

R.

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

Eric Noulard


2017-07-12 21:14 GMT+02:00 René J. V. Bertin <[hidden email]>:
Rolf Eike Beer wrote:

>> It seems that clang handles that variable in a somewhat different manner
>> than GCC does. Even in a very simple call on the commandline (including the
>> -v option) I see it adds -L/opt/local/lib AFTER the user-supplied
>> libraries, where GCC puts it before the 1st -l option.
>
> Welcome to the work of link_directories(). This is exactly the reason to avoid
> it: it always causes trouble.

digikam (that's the project we're talking about) doesn't use neither that nor
target_link_directories. And if CMake simply used the libraries as found and
specified in the target_link_libraries() call I wouldn't have run into problems
either.

AFAIK the explanation you gave. CMake does not seem to play with -l or -L options.

the FindPNG.cmake shipped with CMake does not do that either.
Current digikam does use ${PNG_LIBRARIES} where he should now use  PNG::PNG imported lib.
(introduced in CMake 3.5.0 though)

Which version of CMake are you using?

Which version of digikam are you trying to compile?

Did you try to 

message(STATUS "show me  PNG_LIBRARIES=${PNG_LIBRARIES}")

in the digikam CMakeLists.txt in order to be sure of the content of this in your case.



I did raise a flag on the clang ML though. But whether it's a clang bug or
feature the fact remains that ideally one should be able to tell cmake exactly
what to do, without it trying to outguess the operator.
 
Now I'm lost. If the culprit is a clang feature/bugs then why did you suspect CMake in the frst place?
Does the command line produced by the CMake generator you use (?makefile ?ninja ?) contains
the full path to lib or -L + -l flags?


--
Eric

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

René J. V.  Bertin
Eric Noulard wrote:

> AFAIK the explanation you gave. CMake does not seem to play with -l or -L
> options.

As Rolf said above, apparently it does.

> the FindPNG.cmake shipped with CMake does not do that either.

Indeed, it sets PNG_LIBRARY to the path of libpng, and PNG_LIBRARIES to the 2
required libraries (libpng and libz), both with full path. There would be no
problem if that data ended up in the linker command.

> Which version of CMake are you using?

3.8.2

> Which version of digikam are you trying to compile?

5.6.0

> Did you try to
>
> message(STATUS "show me  PNG_LIBRARIES=${PNG_LIBRARIES}")

Yes, the variable contains the correct 2 paths.

> Now I'm lost. If the culprit is a clang feature/bugs then why did you
> suspect CMake in the frst place?

Because at the end of the day that doesn't matter : CMake must generate
Makefiles that work, and thus has to work around known issues or peculiarities
in the compilers it support. That could be through hardwired exceptions, but in
this case could also be by providing a way to disable rewriting those library
specifications.

Maybe there is, I haven't yet found any documentation whatsoever about the
conditions under which CMake will (supposedly) replace a /path/to/libfoo.so
libspec with -lfoo .

> Does the command line produced by the CMake generator you use (?makefile
> ?ninja ?) contains
> the full path to lib or -L + -l flags?

No. It contains -lpng -lz but no -L flag. See the more specific discussion in
cmake-devel ("FindPNG.cmake doesn't return a LIBRARY_DIR variable").

R.

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

René J. V.  Bertin
In reply to this post by Andreas Naumann
Andreas Naumann wrote:

> cmake instrospects your compiler and asks for system directories.

Just stumbled across this documentation tidbit:

>>>>>>>
CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
--------------------------------------

Implicit linker search path detected for language ``<LANG>``.

Compilers typically pass directories containing language runtime
libraries and default library search paths when they invoke a linker.
These paths are implicit linker search directories for the compiler's
language.  CMake automatically detects these directories for each
language and reports the results in this variable.

When a library in one of these directories is given by full path to
:command:`target_link_libraries` CMake will generate the ``-l<name>`` form on
link lines to ensure the linker searches its implicit directories for the
library.  Note that some toolchains read implicit directories from an
environment variable such as ``LIBRARY_PATH`` so keep its value consistent
when operating in a given build tree.
<<<<<<<

Note the
> CMake will generate the ``-l<name>`` form on link lines to ensure the linker
> searches its implicit directories

What's the point in doing that when a full path is given? Full path means
searching isn't required. Full path (probably) means that the operator wants to
ensure that a specific library is linked. Full path thus means that searching
can even have counterproductive effects.

R.

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

Eric Noulard


2017-07-13 2:04 GMT+02:00 René J. V. Bertin <[hidden email]>:
Andreas Naumann wrote:

> cmake instrospects your compiler and asks for system directories.

Just stumbled across this documentation tidbit:

Thanks you for digging this.
I totally ignored that "feature".

 

>>>>>>>
CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
--------------------------------------

Implicit linker search path detected for language ``<LANG>``.

Compilers typically pass directories containing language runtime
libraries and default library search paths when they invoke a linker.
These paths are implicit linker search directories for the compiler's
language.  CMake automatically detects these directories for each
language and reports the results in this variable.

When a library in one of these directories is given by full path to
:command:`target_link_libraries` CMake will generate the ``-l<name>`` form on
link lines to ensure the linker searches its implicit directories for the
library.  Note that some toolchains read implicit directories from an
environment variable such as ``LIBRARY_PATH`` so keep its value consistent
when operating in a given build tree.
<<<<<<<

Note the
> CMake will generate the ``-l<name>`` form on link lines to ensure the linker
> searches its implicit directories

What's the point in doing that when a full path is given? Full path means
searching isn't required. Full path (probably) means that the operator wants to
ensure that a specific library is linked. Full path thus means that searching
can even have counterproductive effects


I you have a look at file:

you may discovered (as I just did) that not all CMake supported systems kindly accept full path to library for linking...
so may be the implicit system link dir was introduced for them in the first place.
I guess the author/contributor to this part of CMake may certainly explain that better than me.

Looking the code is interesting because apparently what you need is to set  CMP0060 to NEW:

$ cmake --help-policy CMP0060
CMP0060
-------

Link libraries by full path even in implicit directories.
....

The OLD behavior for this policy is to ask the linker to search for
libraries whose full paths are known to be in implicit link directories.
The NEW behavior for this policy is to link libraries by full path even
if they are in implicit link directories.

This policy was introduced in CMake version 3.3.  Unlike most policies,
CMake version 3.7.2 does *not* warn by default when this policy
is not set and simply uses OLD behavior.  See documentation of the
``CMAKE_POLICY_WARNING_CMP0060``
variable to control the warning.


The thing I don't understand is that you use CMake 3.8.2 so you should get the new behavior.
However since digikam does a cmake_minimum_required(VERSION 3.0.0) which may
set the CMP0060 to old.

--
Eric

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

René J. V.  Bertin
Eric Noulard wrote:

> Thanks you for digging this.
> I totally ignored that "feature".

I guess most of us did, it's one of those things that usually works just fine
but that when it breaks sends you on a nasty quest to figure out WTF is going on
(IOW, makes you doubt yourself until you realise you just discovered a hidden
feature).

I found this only because I searched the CMake source tree for LIBRARY_PATH to
see where it does the rewriting. I would never have guessed to find the feature
biting me under the concept "implicit directories".

> I you have a look at file:
>
https://github.com/Kitware/CMake/blob/master/Source/cmComputeLinkInformation.cxx
>
> you may discovered (as I just did) that not all CMake supported systems
> kindly accept full path to library for linking...

CMake being a system that allows to describe how to build a project in a
platform-agnostic way it could easily have handled those systems individually.

> I guess the author/contributor to this part of CMake may certainly explain
> that better than me.

Presumably, and I guess s/he might admit not having thought of (or tested) the
kind of situation where rewriting breaks things.

Something you said in a mail that apparently didn't go to the list:

> OK, but I don't think CMake should "fight" the underlying compiler.

No. Clang may have a reason for the different way of handling LIBRARY_PATH which
means you'd have to leave a possibility for it to work that way - maybe even by
default. But in this case we're not fighting the compiler, we're trying to let
it work another way that is just as supported.

> Looking the code is interesting because apparently what you need is to set
>  CMP0060 to NEW:
>
> $ cmake --help-policy CMP0060
> CMP0060

Ah, great. I would probably have found that by myself, eventually.

> -------
>
> Link libraries by full path even in implicit directories.
> ....
>
> The OLD behavior for this policy is to ask the linker to search for
> libraries whose full paths are known to be in implicit link directories.
> The NEW behavior for this policy is to link libraries by full path even
> if they are in implicit link directories.
>
> This policy was introduced in CMake version 3.3.  Unlike most policies,
> CMake version 3.7.2 does *not* warn by default when this policy
> is not set and simply uses OLD behavior.  See documentation of the
> ``CMAKE_POLICY_WARNING_CMP0060``
> variable to control the warning.
>
>
> The thing I don't understand is that you use CMake 3.8.2 so you should get
> the new behavior.

Are you sure? I read from the description above that you have to set the policy
explicitly.

Do you know if one can set policies like this from the commandline rather than
through patching each toplevel CMakeLists.txt file? Or can it be set for just a
subdirectory?

> However since digikam does a cmake_minimum_required(VERSION 3.0.0) which may
> set the CMP0060 to old.

Quite possible, I've run into naggles with that with another policy on Mac (25).
It's annoying that this happens with digikam which is a really cumbersome
project (it takes ages just to run make just to confirm that everything has been
built).

R.

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

Eric Noulard


2017-07-13 12:07 GMT+02:00 René J. V. Bertin <[hidden email]>:
[...]

>
>
> The thing I don't understand is that you use CMake 3.8.2 so you should get
> the new behavior.

Are you sure? I read from the description above that you have to set the policy
explicitly.

You are right,
 it depends on the cmake_minimum_required statement you gave.
 

Do you know if one can set policies like this from the commandline rather than
through patching each toplevel CMakeLists.txt file? Or can it be set for just a
subdirectory?

From the command line I doubt it.
However CMake handles a policy stack:
 

so that you can enable the NEW behavior of a policy locally in a particular CMakeLists.txt or function etc...


> However since digikam does a cmake_minimum_required(VERSION 3.0.0) which may
> set the CMP0060 to old.

Quite possible, I've run into naggles with that with another policy on Mac (25).
It's annoying that this happens with digikam which is a really cumbersome
project (it takes ages just to run make just to confirm that everything has been
built).

Did you try to use ninja generator instead of make ?
The no-op build is really faster with ninja.

--
Eric

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

René J. V.  Bertin
Eric Noulard wrote:

> From the command line I doubt it.

Adding -DCMAKE_POLICY_DEFAULT_CMP0060=NEW on the commandline works.

But whatever the reason, using PNG::PNG works too. Apparently policy 60 doesn't
affect the IMPORTED_LOCATION target property...


> Did you try to use ninja generator instead of make ?
> The no-op build is really faster with ninja.

I compared single full builds with ninja and make yesterday; with ninja it was
actually (a bit) slower and required more resources (including a larger build
directory). My main gripe with it is that you cannot simply launch a partial
build from a subdirectory.

R

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: /path/to/libpng.so automatic conversion to -lpng ?

Eric Noulard


2017-07-13 13:01 GMT+02:00 René J. V. Bertin <[hidden email]>:
Eric Noulard wrote:

> From the command line I doubt it.

Adding -DCMAKE_POLICY_DEFAULT_CMP0060=NEW on the commandline works.

Good to know.
 

But whatever the reason, using PNG::PNG works too. Apparently policy 60 doesn't
affect the IMPORTED_LOCATION target property...

I guess this is expected and this is one advantage of imported library vs plain path to lib.
 

> Did you try to use ninja generator instead of make ?
> The no-op build is really faster with ninja.

I compared single full builds with ninja and make yesterday; with ninja it was
actually (a bit) slower and required more resources (including a larger build
directory).

Do run make with parallel build?

I was speaking of a no-op build but for full build it may depends on your main memory amount.
Ninja is parallel by default and in some case if you have many core (like 8 or more) but
not so much memory, ninja will generate as many compile/link job as you have core (+2 I think)
which may be too much makes your system swap.

In that case you can control it yourself using
ninja -j <numberOfJob>
or
ninja -l <acceptedLoad>

My main gripe with it is that you cannot simply launch a partial
build from a subdirectory.

Ninja generator is different is it not directory-based because you have a single build.ninja file.
However you can easily build any (sub)directory of your project using:

ninja Path/To/Dir/all

--
Eric

--

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
Loading...