Re: [cmake-developers] Allow ALIAS of IMPORTED targets

[Andreas Schuh]

Hi,

Being able to alias imported targets would be a great feature. Just an
addition to the exports discussion, I also don't think it is necessary.
Besides the EXPORT_NAME property I was not aware of either, I would instead
expect to see an

  add_library (old_name ALIAS new_name)

in the ProjectConfig.cmake(.in) file after importing the new_name library
target. This would make it more clear that it is just an alias for the
actual new exported/imported target. Also no need to maintain copies of
identical imported target properties. I would find this more appealing than
exporting the same target twice but with different name. I would think this
was just done before because of the missing ability to alias an imported
target.

Andreas
On 15 Sep 2015 21:36, "Tamás Kenéz"  wrote:

> Thank you, I was not aware of the EXPORT_NAME target property.
> Tamas
>
> On Tue, Sep 15, 2015 at 7:36 PM, Stephen Kelly  wrote:
>
>> Tamás Kenéz wrote:
>>
>> >> For example, if an ALIAS can be IMPORTED, does it makes sense that it
>> can
>> > be
>> >> exported with export() and install(EXPORT)?
>> >
>> > Yes: couple of months ago I was adding install(EXPORT) to an existing
>> > CMakeList. The name of the library target which I had to export was not
>> > correct as export target name but I was not able change the library
>> target
>> > name because of backward compatibility. Being able to export an alias
>> > would have helped.
>>
>> I still think exporting should be a follow up to allowing IMPORTED ALIAS.
>> Just too keep the branch and discussion as short as possible.
>>
>> Nevertheless, I think you wouldn't need ALIAS targets for your use-case.
>> They are more than you need. You don't need the aliases anywhere except
>> for
>> exporting. So, we could design something which allows you to export
>> aliases,
>> but be completely separate from ALIAS targets.
>>
>> For example,
>>
>>  add_library(foo ${foo_SRCS})
>>  set_target_property(foo EXPORT_NAMES foo foo_old_name)
>>
>>  ...
>>
>>  install(EXPORT ...)
>>
>> resulting in a generated file containing
>>
>>  add_library(foo IMPORTED)
>>  ...
>>
>>  add_library(foo_old_name IMPORTED)
>>  ...
>>
>> where each of the generated targets get the same target properties.
>>
>> Note that there is already an EXPORT_NAME target property
>>
>>  http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html
>>
>> but it is not a list, so the task would probably be to deprecate that one
>> and add EXPORT_NAMES.
>>
>> I filed
>>
>>  http://public.kitware.com/Bug/view.php?id=15745
>>
>> Thanks,
>>
>> Steve.
>>
>>
>>
>> --
>>
>> 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
>>
>
>
> --
>
> 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
>
-- 

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

Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version

[James Johnston]

> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of Brad King
> Sent: Friday, September 18, 2015 18:24
> To: Gilles Khouzam
> Cc: cmake-developers@cmake.org
> Subject: Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows:
> Correctly determine Windows version
> 
> On 09/10/2015 07:24 PM, Gilles Khouzam wrote:
> > This patch adds a simple version manifest
> > Source\cmake.version.manifest to the CMake executables.
> 
> After working out the support for manifests across all generators as
> discussed elsewhere in this thread, I've added your manifest file to
CMake's
> own build:
> 
>  Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674)
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551

While on the subject, there are some other additions to the manifest you
might want to consider.









The above block will disable UAC heuristics on Windows Vista and above, such
that elevation won't ever be requested.  It will also disable the Program
Compatibility Assistant for Vista IIRC.  (as I understand it, supportedOS
wasn't added until Windows 7.  Why there is a GUID in there for Vista, I'm
not sure.  App manifests are not the best documented thing on MSDN IMHO.)
It would probably be appropriate to use this for all CMake executables.







The above block will declare a preference to use the newer common controls
library introduced with Windows XP.  Without this, Windows will fall back on
the old Windows 2000 era of common controls (i.e. Windows 95 style buttons).
This would be appropriate for cmake-gui.  Since it uses Qt though, the
effect is probably minimal, but if some API were called such that native
Win32 controls were used somewhere, this would improve the appearance.



http://schemas.microsoft.com/SMI/2005/WindowsSettings;>
True/PM




The above block will make the cmake-gui DPI aware, such that DPI
virtualization is disabled on Windows Vista and above.  In laymen's terms,
it fixes "blurry text".  It looks like Qt already does this (I just tested
CMake 3.3 on a high DPI profile.)  See http://doc.qt.io/qt-5/highdpi.html.
Probably they do it by calling the SetProcessDpiAwareness function.
However, this API has some caveats; from MSDN:

" The SetProcessDPIAware function in Windows Vista and later versions sets
the current process as DPI-aware. However, the use of the SetProcessDPIAware
function is discouraged. For example, if a DLL caches DPI settings during
initialization, invoking SetProcessDPIAware in your application might
generate a possible race condition. For this reason, we recommend that an
application enable DPI awareness by using the application's assembly
manifest rather than by calling SetProcessDPIAware." ---
https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).a
spx

And also:

" If you use the SetProcessDpiAwareness method to set the DPI awareness
level, you must call SetProcessDpiAwareness prior to any Win32API call that
forces the system to begin virtualization."

The safer path seems to me to be put it in the manifest, as recommended by
MSFT.  Note there are two possible values:  "True" and "True/PM".  "PM"
stands for per-monitor DPI aware (introduced with Windows 8.1).  Looks like
Qt supports PM now, but since it was introduced in Windows 8.1, probably
only very recent versions of Qt.  You'd have to be careful what is in the
manifest agrees with the version of Qt being used. (e.g. you don't want to
declare "True/PM" on a non-PM older version of Qt, else no per-monitor
scaling would happen at all - virtualized or otherwise).

Since Qt does call SetProcessDPIAware and cmake-gui does seem to scale OK
right now, including this block may end up being a little "pointless" in
practice, despite the caveats from MSDN above.



Finally there is this block; I'm not exactly sure which versions of Windows
might actually require this or what.  I'm a little fuzzy on why I included
it.  Most of the built-in Windows accessories seem to have this in their
manifests though.  IIRC it's especially needed with the common controls
manifest block.

Best regards,

James Johnston

-- 

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

Re: [cmake-developers] Generator expressions for install destination

[Robert Goulet]

Here's a version that is more conservative. It doesn't change the 
install(EXPORT) behavior. install(TARGET) already supported genex, so basically 
this patch adds install(FILES) destination genex.

Perhaps we should update the Help to only mention install(FILES) destination 
instead of all variations of install?

I don't have time to work on install(EXPORT) yet. I think it would still be 
good to have install(FILES) merged even if install(EXPORT) isn't done yet.

Thanks!

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Thursday, September 10, 2015 11:07 AM
To: Robert Goulet 
Cc: cmake-developers@cmake.org
Subject: Re: Generator expressions for install destination

On 09/09/2015 12:21 PM, Robert Goulet wrote:
> Here's the patch to add generator expressions to the install command 
> DESTINATION option.

Thanks for the update.

>>This should not be needed if things are factored correctly.
>>Everything in that block already passes "config" through as a parameter.
> 
> None of the places where I use GetDestination, except in 
> cmInstallTargetGenerator, receives a config in parameter.
> An ideally, the ConfigurationName member should not even exist, but 
> that will force all places to pass the config as a parameter.
> Imho it's better to keep refactoring in a separate patch.

I think such a separate refactoring patch should come first.
I cannot review the logic with confidence because I don't know what implicitly 
depends on ConfigurationName being set and whether call paths leading to it set 
it correctly.

Also, take a look at the install(EXPORT) case.  I tried using a $ genex 
in the DESTINATION argument with your patch but it fails trying to create a 
directory with literal $ in its name (on Windows with a VS generator).  
Note that the
install(EXPORT) command generates some files in the build tree packed away 
under CMakeFiles/Export and then adds cmake_install.cmake rules to install 
those.  Generation of these files needs to expand the generator expression in 
time.

Thanks,
-Brad



install-dest-genex.patch
Description: install-dest-genex.patch
-- 

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

Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version

[Gilles Khouzam]

Great. Thanks

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Friday, September 18, 2015 11:24
To: Gilles Khouzam 
Cc: cmake-developers@cmake.org
Subject: Re: [PATCH] [CMake 0015674]: Windows: Correctly determine Windows 
version

On 09/10/2015 07:24 PM, Gilles Khouzam wrote:
> This patch adds a simple version manifest 
> Source\cmake.version.manifest to the CMake executables.

After working out the support for manifests across all generators as discussed 
elsewhere in this thread, I've added your manifest file to CMake's own build:

 Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551

Thanks,
-Brad

-- 

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

Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version

[Brad King]

On 09/10/2015 07:24 PM, Gilles Khouzam wrote:
> This patch adds a simple version manifest Source\cmake.version.manifest
> to the CMake executables.

After working out the support for manifests across all generators
as discussed elsewhere in this thread, I've added your manifest
file to CMake's own build:

 Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674)
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551

Thanks,
-Brad

-- 

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

[cmake-developers] CPack/NSIS is broken after extended length paths fix

[Dmitry Kochkin]

 Hi Clinton,

I was looking into an issue that we have in CMake on Windows with extended 
paths and later on realized that you've fixed it.
However I've realized that you fixed it only in cmSystemTools, which fixes e.g. 
INSTALL, but does not fix cpack.

Actually it's even worse because in current master HEAD I can see that INST_DIR 
is empty in generated project:
  !define INST_DIR ""
(not sure if that's caused by your change)

I've figured out that NSIS was not going to fix this (see  
http://sourceforge.net/p/nsis/feature-requests/241/ )
I've made a small patch to NSIS generator and template to put infamous \\?\ 
there.

I can send directly to you as I guess you know more about these parts of code.

Best regards,
Dmitry Kochkin

-- 

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

[cmake-developers] [CMake 0015751]: cmake Qt moc files' autogen failed with Q_OBJECT in source code comments

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15751 
== 
Reported By:Dmitriy V. Shmykov
Assigned To:
== 
Project:CMake
Issue ID:   15751
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-09-18 09:37 EDT
Last Modified:  2015-09-18 09:37 EDT
== 
Summary:cmake Qt moc files' autogen failed with Q_OBJECT in
source code comments
Description: 
When I compile my source code which contains the text "Q_OBJECT" in C++ comments
cmake fails with the error text "AUTOGEN: error: .cpp: The file contains a
Q_OBJECT macro, but does not include .moc"

Steps to Reproduce: 
create a project with

set(CMAKE_AUTOMOC ON)

and C++ source code file containing comments with "Q_OBJECT" substring.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-09-18 09:37 Dmitriy V. ShmykovNew Issue
==

-- 

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

Re: [cmake-developers] CMake user-provided manifest files

[Brad King]

On 09/16/2015 07:01 PM, James Johnston wrote:
> That fixed it; just tested building a pile of projects with both Ninja and
> VS2008 generators (with VS2008 used with Ninja). 

Great, thanks for testing.  A revision of the commit is now in 'master':

 Add support for *.manifest source files with MSVC tools
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e134e53b

-Brad

-- 

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

Re: [cmake-developers] [CPackDeb] use of internal md5sum function

[Domen Vrankar]

> Please find attached a patch on CPackDeb
> - which calls the internal function for md5sum computation
> - which prevents the hash of the symlinks
>
> I believe this fixes the issue (partially or totally)
>
> https://public.kitware.com/Bug/view.php?id=13386
>

Applied with minor changes to lintian test result verification:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=7c7874c8

Thanks,
Domen
-- 

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

Re: [cmake-developers] CPack/NSIS is broken after extended length paths fix

[clinton]

- On Sep 18, 2015, at 6:07 AM, Dmitry Kochkin  wrote: 

> Hi Clinton,

> I was looking into an issue that we have in CMake on Windows with extended 
> paths
> and later on realized that you've fixed it.
> However I've realized that you fixed it only in cmSystemTools, which fixes 
> e.g.
> INSTALL, but does not fix cpack.
Yes, I was fixing the 'install' to work with paths > 260 characters, and was 
using the cpack archive generator at the time. 
With the path to the build tree, plus the "_CPackPackage/", some of these 
paths can become quite long. 

> Actually it's even worse because in current master HEAD I can see that 
> INST_DIR
> is empty in generated project:
> !define INST_DIR ""
> (not sure if that's caused by your change)
Interesting... Do you know why this happens? How is this problem related to 
extended paths (with the \\?\ prefix)? Do you have an example to demonstrate 
this problem? 

> I've figured out that NSIS was not going to fix this (see
> http://sourceforge.net/p/nsis/feature-requests/241/ )
Maybe they'll accept a patch to fix it there? Was there any effort to fix it 
there? 

> I've made a small patch to NSIS generator and template to put infamous \\?\
> there.

> I can send directly to you as I guess you know more about these parts of code.

You can send your patch to this mailing list for review. 

Clint 
-- 

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