2017-07-13 13:01 GMT+02:00 René J. V. Bertin :
> 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
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
2017-07-13 12:07 GMT+02:00 René J. V. Bertin :
[...]
>
> >
> > 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
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
2017-07-13 2:04 GMT+02:00 René J. V. Bertin :
> 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".
>
> >>>
Andreas Naumann wrote:
> cmake instrospects your compiler and asks for system directories.
Just stumbled across this documentation tidbit:
>>>
CMAKE__IMPLICIT_LINK_DIRECTORIES
--
Implicit linker search path detected for language .
Compilers
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
2017-07-12 21:14 GMT+02:00 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
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
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
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
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
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
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
14 matches
Mail list logo