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

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

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

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

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

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

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

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

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

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

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

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

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15751 == Reported By:Dmitriy V. Shmykov Assigned To:

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

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

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

> 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

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

- 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