[cmake-developers] Is there a way to avoid LOCATION property with Qt5?

[J Decker]

many places that you would use LOCATION you can use generator expressions
http://www.cmake.org/cmake/help/v3.0/manual/cmake-generator-expressions.7.html

$<TARGET_FILE_DIR:targetname>

On Tue, Apr 28, 2015 at 12:30 AM, Alan W. Irwin <irwin at beluga.phys.uvic.ca>
wrote:

> Hi Nils:
>
> Thanks for your quick reply.  More below in context.
>
>
> On 2015-04-28 08:45+0200 Nils Gladitz wrote:
>
>  On 04/28/2015 08:00 AM, Alan W. Irwin wrote:
>>
>>> The Qt5 cmake documentation at
>>> <http://doc.qt.io/qt-5/cmake-manual.html> which Steve has referred me
>>> to before states you should use the LOCATION property of targets to
>>> determine the actual path to libraries. The PLplot build system
>>> requires those locations so it can transform them into the -L and -l
>>> form required to generate its pkg_config *.pc files.
>>>
>>> Some time ago I got this process to work fine for CMP0026 OLD and Qt5,
>>> but
>>> what is the alternative I should use for the CMP0026 NEW case (which
>>> disallows using the LOCATION property for targets)?
>>>
>>> Note PLplot uses a minimum CMake version of 3.0.2 so I am looking for
>>> a CMP0026 NEW solution that works for that version or above for Qt5.
>>>
>>
>> CMP0026 only applies to build targets.
>>
>> The location of build targets is still in flux during configuration which
>> is why getting the location of those during configuration time is unsafe.
>>
>> For imported targets this does not apply since their location is fixed.
>>
>
> OK.  Thanks, for pointing that out.  Could you make that more obvious
> in <http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html>, i.e.
> change the summary line from
>
> Disallow use of the LOCATION target property.
>
> ==>
>
> Disallow use of the LOCATION property for build targets.
>
> I took that summary line to mean exactly what it said and just plain
> missed the reference to build targets that is in the first paragraph
> of that documenation.
>
>
>> For which configuration LOCATION returns isn't defined but I suppose that
>> may not matter for pkg-config.
>>
>> Otherwise you may want to look into LOCATION_<CONFIG>.
>>
>
> I don't understand exactly what you mean by "configuration LOCATION
> returns".  From what you said that term means something different from
> LOCATION_<CONFIG> and in any case is not relevant to my use case of
> generating pkg-config *.pc files with our build system, but I am
> nevertheless curious about what you meant.)
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> --
>
> 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-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150428/50d5942a/attachment-0001.html>