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
