Re: [CMake] cmake needs 2 runs to find boost

2015-11-05 Thread Peter Steinbach
I guess, nobody has a hint on what to look at or what to try?
Best,
Peter

On Tuesday, November 03, 2015 02:10:54 PM Peter Steinbach wrote:
> Hi to all,
> 
> I tested this with cmake 3.2.2 and 3.3.2 and still get the same problem.
> I'd like to use boost with gcc on windows 7 64bit. I installed boost and gcc
> with msys2 as I cannot use MSVC for the actual project I am looking into
> for this.
> 
> the funny thing, if I use the attached CMakeLists.txt on the machine and
> call: ```
> $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 -
> DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib ..
> -- The CXX compiler identification is GNU 4.9.2
> -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe
> -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> setting win specific stuff
> CMake Error at C:/Program Files
> (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message):
>   Unable to find the requested Boost libraries.
> 
>   Boost version: 1.57.0
> 
>   Boost include path: C:/msys64/mingw64/include
> 
>   Could not find the following static Boost libraries:
> 
>   boost_filesystem
>   boost_system
> 
>   No Boost libraries were found.  You may need to set BOOST_LIBRARYDIR to
> the directory containing Boost libraries or BOOST_ROOT to the location of
> Boost.
> Call Stack (most recent call first):
>   CMakeLists.txt:17 (FIND_PACKAGE)
> 
> 
> CMake Error at CMakeLists.txt:24 (MESSAGE):
>   Boost not found (C:/msys64/mingw64)
> 
> 
> -- Configuring incomplete, errors occurred!
> See also
> "C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMakeFil
> es/CMakeOutput.log". $ cmake -G "MSYS Makefiles"
> -DBOOST_ROOT=C:/msys64/mingw64 -
> DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib ..
> setting win specific stuff
> Boost 1.57 found __
> -- Configuring done
> -- Generating done
> -- Build files have been written to:
> C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build
> ```
> 
> I'd like to link statically to multithreaded libboost_*-mt.a from my app.
> But it proofes really hard to find Boost in the first place.
> Any ideas?
> 
> Peter

-- 
Peter Steinbach, Dr. rer. nat.
HPC Developer

Scionics Computer Innovation GmbH
Löscherstr. 16
01309 Dresden
fon: +49 351 210 2882
fax: +49 351 210 1689
http://www.scionics.de

Sitz der Gesellschaft:  Dresden (Main office)
Amtsgericht - Registergericht:  Dresden HRB 20337 (Commercial Registry)
Ust-IdNr.:  DE813263791 (VAT ID Number)
Geschäftsführer:  John Duperon, Jeff Oegema (Managing Directors)
-- 

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


Re: [CMake] Cmake not working for VS13

2015-11-05 Thread David Cole via CMake
What version of Visual Studio do you have installed?


On Thursday, November 5, 2015, Nikita Barawade <
nikita.baraw...@einfochips.com> wrote:

> Hi,
>
>
> New to cmake utility,
>
> I am trying to build sample program given here
> https://cognitivewaves.wordpress.com/cmake-and-visual-studio/ with VS13
> on windows 7.
>
> Getting following error:
>
> CMake Error at CMakeLists.txt:5 (project): No CMAKE_C_COMPILER could be
> found.
>
> CMake Error at CMakeLists.txt:5 (project): No CMAKE_CXX_COMPILER could be
> found.
>
>
> I searched on Internet but not getting required info.
>
>
> Note:
>
> cmake version 3.4.0
>
> using native compiler option to configure.
>
>
>
> Can anyone give some pointers ?
>
>
> CMake and Visual Studio | Cognitive Waves
> 
> cognitivewaves.wordpress.com
> Introduction Visual Studio to CMake Mapping Example Source Structure
> Execute CMake Visual Studio Solution Explorer View Build and Run
>
>
>
> Regards,
> Nikita
>
> *
> eInfochips Business Disclaimer: This e-mail message and all attachments
> transmitted with it are intended solely for the use of the addressee and
> may contain legally privileged and confidential information. If the reader
> of this message is not the intended recipient, or an employee or agent
> responsible for delivering this message to the intended recipient, you are
> hereby notified that any dissemination, distribution, copying, or other use
> of this message or its attachments is strictly prohibited. If you have
> received this message in error, please notify the sender immediately by
> replying to this message and please delete it from your computer. Any views
> expressed in this message are those of the individual sender unless
> otherwise stated. Company has taken enough precautions to prevent the
> spread of viruses. However the company accepts no liability for any damage
> caused by any virus transmitted by this email.
> *
>
>
-- 

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

Re: [CMake] cmake needs 2 runs to find boost

2015-11-05 Thread Peter Steinbach
Hi Benedikt,

interesting thought, however I wonder why cmake is then capable of deducing 
the right boost version and include path. Just inside the first error message, 
I see:
(x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message):
> >Unable to find the requested Boost libraries.
> >
> >Boost version: 1.57.0
> >
> >Boost include path: C:/msys64/mingw64/include
> >
> >Could not find the following static Boost libraries:
> >boost_filesystem
> >boost_system

strange, isn't it?
Peter


On Thursday, November 05, 2015 11:41:10 AM Benedikt Hegner wrote:
> Hi Peter,
> 
> as I don't use windows at all, this is just a very wild guess...
> 
> Could it be that in the second run you actually don't use
>/CMake/share/cmake-3.2/Modules/FindBoost.cmake
> but boost-config.cmake, which it now finds in the cached environment of
> the first run?
> 
> This assumes of course that you built boost w/ CMake and not bjam...
> 
> Cheers,
>Benedikt
> 
> On 03.11.2015 14:10, Peter Steinbach wrote:
> > Hi to all,
> > 
> > I tested this with cmake 3.2.2 and 3.3.2 and still get the same problem.
> > I'd like to use boost with gcc on windows 7 64bit. I installed boost and
> > gcc with msys2 as I cannot use MSVC for the actual project I am looking
> > into for this.
> > 
> > the funny thing, if I use the attached CMakeLists.txt on the machine and
> > call: ```
> > $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 -
> > DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib ..
> > -- The CXX compiler identification is GNU 4.9.2
> > -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe
> > -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > -- Detecting CXX compile features
> > -- Detecting CXX compile features - done
> > setting win specific stuff
> > CMake Error at C:/Program Files
> > 
> > (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message):
> >Unable to find the requested Boost libraries.
> >
> >Boost version: 1.57.0
> >
> >Boost include path: C:/msys64/mingw64/include
> >
> >Could not find the following static Boost libraries:
> >boost_filesystem
> >boost_system
> >
> >No Boost libraries were found.  You may need to set BOOST_LIBRARYDIR to
> >the
> >directory containing Boost libraries or BOOST_ROOT to the location of
> >Boost.
> > 
> > Call Stack (most recent call first):
> >CMakeLists.txt:17 (FIND_PACKAGE)
> > 
> > CMake Error at CMakeLists.txt:24 (MESSAGE):
> >Boost not found (C:/msys64/mingw64)
> > 
> > -- Configuring incomplete, errors occurred!
> > See also
> > "C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMakeF
> > iles/CMakeOutput.log". $ cmake -G "MSYS Makefiles"
> > -DBOOST_ROOT=C:/msys64/mingw64 -
> > DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib ..
> > setting win specific stuff
> > Boost 1.57 found __
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to:
> > C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build
> > ```
> > 
> > I'd like to link statically to multithreaded libboost_*-mt.a from my app.
> > But it proofes really hard to find Boost in the first place.
> > Any ideas?
> > 
> > Peter

-- 
Peter Steinbach, Dr. rer. nat.
HPC Developer

Scionics Computer Innovation GmbH
Löscherstr. 16
01309 Dresden
fon: +49 351 210 2882
fax: +49 351 210 1689
http://www.scionics.de

Sitz der Gesellschaft:  Dresden (Main office)
Amtsgericht - Registergericht:  Dresden HRB 20337 (Commercial Registry)
Ust-IdNr.:  DE813263791 (VAT ID Number)
Geschäftsführer:  John Duperon, Jeff Oegema (Managing Directors)
-- 

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


Re: [CMake] [CDash] CTEST_CUSTOM_WARNING_EXECPTION

2015-11-05 Thread David Cole via CMake
Does your ctest -S script call ctest_read_custom_files
https://cmake.org/cmake/help/v3.4/command/ctest_read_custom_files.html
after ctest_configure?


On Thursday, November 5, 2015, Rashad M  wrote:

> Hello all,
>
> I have CTestCustom.cmake.in file in source tree with the following
> contents
>
>
> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in
>
> during ctest build CTestCustom.cmake file is getting generated inside the
> build tree.
>
> But however the warnings are not filtered out on the dashboard. For
> instance, see the dashboard submission
> http://dash.orfeo-toolbox.org/viewBuildError.php?type=1=206112
>
> and see the exception for vcl_deprecated_header
>
>
> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69
>
> The warning appears on dashobard anyway. Can someone point me in the right
> direction. ?
>
> Thanks in advance.
>
>
> CMake Version:
> 2.8.12.2
>
> CDash Version:
> 2.2.3
>
> uname -a
> Linux ubuntu
>
>  3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64
> x86_64 x86_64 GNU/Linux
> --
> Regards,
>Rashad
>
-- 

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

Re: [CMake] Cmake not working for VS13

2015-11-05 Thread Nikita Barawade


Hi,


Thanks for reply .
I am using visual studio 13.

I managed to get it done , I had to repair  Visual studio .


Regards,
Nikita Barawade
Engineer | PES



From: David Cole 
Sent: 05 November 2015 06:00 PM
To: Nikita Barawade
Cc: cmake@cmake.org
Subject: Re: [CMake] Cmake not working for VS13

What version of Visual Studio do you have installed?


On Thursday, November 5, 2015, Nikita Barawade 
> wrote:

Hi,


New to cmake utility,

I am trying to build sample program given here 
https://cognitivewaves.wordpress.com/cmake-and-visual-studio/ with VS13 on 
windows 7.

Getting following error:

CMake Error at CMakeLists.txt:5 (project): No CMAKE_C_COMPILER could be found.

CMake Error at CMakeLists.txt:5 (project): No CMAKE_CXX_COMPILER could be found.


I searched on Internet but not getting required info.


Note:

cmake version 3.4.0

using native compiler option to configure.



Can anyone give some pointers ?


CMake and Visual Studio | Cognitive 
Waves
cognitivewaves.wordpress.com
Introduction Visual Studio to CMake Mapping Example Source Structure Execute 
CMake Visual Studio Solution Explorer View Build and Run




Regards,
Nikita

*
 eInfochips Business Disclaimer: This e-mail message and all attachments 
transmitted with it are intended solely for the use of the addressee and may 
contain legally privileged and confidential information. If the reader of this 
message is not the intended recipient, or an employee or agent responsible for 
delivering this message to the intended recipient, you are hereby notified that 
any dissemination, distribution, copying, or other use of this message or its 
attachments is strictly prohibited. If you have received this message in error, 
please notify the sender immediately by replying to this message and please 
delete it from your computer. Any views expressed in this message are those of 
the individual sender unless otherwise stated. Company has taken enough 
precautions to prevent the spread of viruses. However the company accepts no 
liability for any damage caused by any virus transmitted by this email. 
*
-- 

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

Re: [CMake] cmake needs 2 runs to find boost

2015-11-05 Thread Benedikt Hegner

Hi Peter,

as I don't use windows at all, this is just a very wild guess...

Could it be that in the second run you actually don't use
  /CMake/share/cmake-3.2/Modules/FindBoost.cmake
but boost-config.cmake, which it now finds in the cached environment of 
the first run?


This assumes of course that you built boost w/ CMake and not bjam...

Cheers,
  Benedikt

On 03.11.2015 14:10, Peter Steinbach wrote:

Hi to all,

I tested this with cmake 3.2.2 and 3.3.2 and still get the same problem.
I'd like to use boost with gcc on windows 7 64bit. I installed boost and gcc
with msys2 as I cannot use MSVC for the actual project I am looking into for
this.

the funny thing, if I use the attached CMakeLists.txt on the machine and call:
```
$ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 -
DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib ..
-- The CXX compiler identification is GNU 4.9.2
-- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe
-- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
setting win specific stuff
CMake Error at C:/Program Files
(x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message):
   Unable to find the requested Boost libraries.

   Boost version: 1.57.0

   Boost include path: C:/msys64/mingw64/include

   Could not find the following static Boost libraries:

   boost_filesystem
   boost_system

   No Boost libraries were found.  You may need to set BOOST_LIBRARYDIR to the
   directory containing Boost libraries or BOOST_ROOT to the location of
   Boost.
Call Stack (most recent call first):
   CMakeLists.txt:17 (FIND_PACKAGE)


CMake Error at CMakeLists.txt:24 (MESSAGE):
   Boost not found (C:/msys64/mingw64)


-- Configuring incomplete, errors occurred!
See also
"C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMakeFiles/CMakeOutput.log".
$ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 -
DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib ..
setting win specific stuff
Boost 1.57 found __
-- Configuring done
-- Generating done
-- Build files have been written to:
C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build
```

I'd like to link statically to multithreaded libboost_*-mt.a from my app. But
it proofes really hard to find Boost in the first place.
Any ideas?

Peter





-- 

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

[CMake] [CDash] CTEST_CUSTOM_WARNING_EXECPTION

2015-11-05 Thread Rashad M
Hello all,

I have CTestCustom.cmake.in file in source tree with the following contents

https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in

during ctest build CTestCustom.cmake file is getting generated inside the
build tree.

But however the warnings are not filtered out on the dashboard. For
instance, see the dashboard submission
http://dash.orfeo-toolbox.org/viewBuildError.php?type=1=206112

and see the exception for vcl_deprecated_header

https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69

The warning appears on dashobard anyway. Can someone point me in the right
direction. ?

Thanks in advance.


CMake Version:
2.8.12.2

CDash Version:
2.2.3

uname -a
Linux ubuntu

 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux
-- 
Regards,
   Rashad
-- 

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

Re: [cmake-developers] [PATCH 0/3] Support for multilingual SLAs for the CPack DMG generator

2015-11-05 Thread Levermann, Simon
Hi Brad,

the attached patch limits lines to 79 cols, and adds the necessary
documentation to the variables and release notes.

I added diagnostic pragmas to suppress the deprecation warnings as well
as a comment explaining the need for them. I've looked for a
replacement some more, but I still haven't been able to find anything.
I could try to hard-code it by writing a simple program that iterates
all possible language codes (it's "only" a 16-bit value, so 2^16
combinations). However, this feels even hackier to me than the current
state.

This patch is a single commit rebased on current master
(60cbd9b9da2059481e2f29fbb5859a5b0643d3d7)

Kind regards,
Simon

On Mi, 2015-11-04 at 10:46 -0500, Brad King wrote:
> On 11/03/2015 06:09 AM, Levermann, Simon wrote:
> > This adds support for multilingual SLAs which are displayed when
> > the user is trying to mount the DMG.
> 
> Thanks for working on this and for bringing the patch to this list.
> 
> Patches 2 and 3 look like fixups.  Please squash that all into one
> commit.  Also please keep C++ sources wrapped to 79 columns or less.
> 
> > Multiple languages can be added via the new variables
> > CPACK_DMG_SLA_DIR
> > and CPACK_DMG_SLA_LANGUAGES.
> 
> Please add Help/variable/*.rst files to document these.  Also
> please add a Help/release/dev/*.rst file to add a release note
> for the feature.
> 
> > For each language defined, CPack will search for a
> > language.menu.txt
> > and language.license.txt file in CPACK_SLA_DIR.
> 
> Good.  Please mention this in the above-requested documentation.
> 
> > This patch adds a library to the deprecated Carbon Framework to
> > CPackLib, since the functions/types required to acquire the region
> > code for the internal LPic data structure are only available in
> > this
> > old API. Apple does not seem to be offering a replacement API for
> > the
> > old ScriptManager region codes.
> 
> Hopefully an alternative can be found.  Meanwhile I get warnings
> during the build due to DEPRECATED_IN_MAC_OS_X_VERSION_10_6_AND_LATER
> appearing on the declarations of these APIs.  Please add pragmas
> or whatever is needed to suppress them, at least with Clang.  Call
> out the purpose for the suppression with a comment explaining why
> we need to use the deprecated APIs.
> 
> > Additional thought: One could add the language.menu.txt files for
> > some common languages to the repository.
> 
> Let's defer that until the actual feature is working.
> 
> Thanks,
> -Brad
> From 68bd81a62f7c4a11cb0bc46a64d6b0da0a8a6688 Mon Sep 17 00:00:00 2001
From: Simon Levermann 
Date: Mon, 19 Oct 2015 11:13:55 +0200
Subject: [PATCH] Add support for multilingual SLAs

Multiple languages for SLAs and the SLA UI can be added via the CPack variables
CPACK_DMG_SLA_DIR and CPACK_DMG_SLA_LANGUAGES. For each language defined in the
languages variable, CPack will search for .menu.txt and
.license.txt in CPACK_DMG_SLA_DIR. If the sla directory variable is not
defined, the old behaviour using CPACK_RESOURCE_FILE_LICENSE is retained

Pass string by const& instead of copying

Remove superfluous assignment

Add deprecation pragma and comment

Break lines longer than 79 characters

Add variable documentation for new CPACK_DMG_ variables

Add release note for multilanguage-sla
---
 Help/release/dev/cpack-dmg-multilanguage-sla.txt |   6 +
 Help/variable/CPACK_DMG_SLA_DIR  |   6 +
 Help/variable/CPACK_DMG_SLA_LANGUAGES|   6 +
 Source/CMakeLists.txt|   4 +
 Source/CPack/cmCPackDragNDropGenerator.cxx   | 357 ---
 Source/CPack/cmCPackDragNDropGenerator.h |  10 +
 6 files changed, 351 insertions(+), 38 deletions(-)
 create mode 100644 Help/release/dev/cpack-dmg-multilanguage-sla.txt
 create mode 100644 Help/variable/CPACK_DMG_SLA_DIR
 create mode 100644 Help/variable/CPACK_DMG_SLA_LANGUAGES

diff --git a/Help/release/dev/cpack-dmg-multilanguage-sla.txt b/Help/release/dev/cpack-dmg-multilanguage-sla.txt
new file mode 100644
index 000..cdf3162
--- /dev/null
+++ b/Help/release/dev/cpack-dmg-multilanguage-sla.txt
@@ -0,0 +1,6 @@
+cpack-dmg-multilanguage-sla
+--
+
+* This feature adds the capability to add multi-lingual SLAs to a DMG which
+  is presented to the user when they try to mount the DMG. See :variable:`CPACK_DMG_SLA_LANGUAGES`
+  and :variable:`CPACK_DMG_SLA_DIR` for usage information.
diff --git a/Help/variable/CPACK_DMG_SLA_DIR b/Help/variable/CPACK_DMG_SLA_DIR
new file mode 100644
index 000..7b38a23
--- /dev/null
+++ b/Help/variable/CPACK_DMG_SLA_DIR
@@ -0,0 +1,6 @@
+CPACK_DMG_SLA_DIR
+
+
+Directory where license and menu files for different languages are stored
+
+See :variable:`CPACK_DMG_SLA_LANGUAGES` for more information.
diff --git a/Help/variable/CPACK_DMG_SLA_LANGUAGES b/Help/variable/CPACK_DMG_SLA_LANGUAGES
new file mode 100644
index 000..77eef61
--- /dev/null
+++ b/Help/variable/CPACK_DMG_SLA_LANGUAGES

[CMake] Fwd: Re: cmake needs 2 runs to find boost

2015-11-05 Thread Peter Steinbach
--  Forwarded Message  --

Subject: Re: [CMake] cmake needs 2 runs to find boost
Date: Thursday, November 05, 2015, 04:41:51 PM
From: Andreas Naumann 
To: Peter Steinbach 

Hey Peter,

It is not a solution, but I would set Boost_DEBUG to ON and compare the 
output of the first and the second cmake run.

Andreas
Am 05.11.2015 um 14:26 schrieb Peter Steinbach:
> Hi to all,
>
> ok, I tried the attached minimal CMakeLists.txt again and found out that it
> fails in the way I described only with the "MSYS Makefiles" generator. If I
> use the same CMakeLists.txt without a custom generator (so MSVS is the 
default
> IIRC), the libraries are found alright!
>
> Any ideas?
> Best,
> Peter
>
> On Thursday, November 05, 2015 01:41:33 PM Peter Steinbach wrote:
>> Hi Benedikt,
>>
>> interesting thought, however I wonder why cmake is then capable of deducing
>> the right boost version and include path. Just inside the first error
>> message, I see:
>>
>> (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message):
 Unable to find the requested Boost libraries.
 
 Boost version: 1.57.0
 
 Boost include path: C:/msys64/mingw64/include
 
 Could not find the following static Boost libraries:
 boost_filesystem
 boost_system
>> strange, isn't it?
>> Peter
>>
>> On Thursday, November 05, 2015 11:41:10 AM Benedikt Hegner wrote:
>>> Hi Peter,
>>>
>>> as I don't use windows at all, this is just a very wild guess...
>>>
>>> Could it be that in the second run you actually don't use
>>>
>>> /CMake/share/cmake-3.2/Modules/FindBoost.cmake
>>>
>>> but boost-config.cmake, which it now finds in the cached environment of
>>> the first run?
>>>
>>> This assumes of course that you built boost w/ CMake and not bjam...
>>>
>>> Cheers,
>>>
>>> Benedikt
>>>
>>> On 03.11.2015 14:10, Peter Steinbach wrote:
 Hi to all,

 I tested this with cmake 3.2.2 and 3.3.2 and still get the same problem.
 I'd like to use boost with gcc on windows 7 64bit. I installed boost and
 gcc with msys2 as I cannot use MSVC for the actual project I am looking
 into for this.

 the funny thing, if I use the attached CMakeLists.txt on the machine and
 call: ```
 $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 -
 DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib ..
 -- The CXX compiler identification is GNU 4.9.2
 -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe
 -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works
 -- Detecting CXX compiler ABI info
 -- Detecting CXX compiler ABI info - done
 -- Detecting CXX compile features
 -- Detecting CXX compile features - done
 setting win specific stuff
 CMake Error at C:/Program Files

 (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message):
 Unable to find the requested Boost libraries.
 
 Boost version: 1.57.0
 
 Boost include path: C:/msys64/mingw64/include
 
 Could not find the following static Boost libraries:
 boost_filesystem
 boost_system
 
 No Boost libraries were found.  You may need to set BOOST_LIBRARYDIR
 to
 the
 directory containing Boost libraries or BOOST_ROOT to the location of
 Boost.

 Call Stack (most recent call first):
 CMakeLists.txt:17 (FIND_PACKAGE)

 CMake Error at CMakeLists.txt:24 (MESSAGE):
 Boost not found (C:/msys64/mingw64)

 -- Configuring incomplete, errors occurred!
 See also
 "C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMak
 eF
 iles/CMakeOutput.log". $ cmake -G "MSYS Makefiles"
 -DBOOST_ROOT=C:/msys64/mingw64 -
 DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib ..
 setting win specific stuff
 Boost 1.57 found __
 -- Configuring done
 -- Generating done
 -- Build files have been written to:
 C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build
 ```

 I'd like to link statically to multithreaded libboost_*-mt.a from my
 app.
 But it proofes really hard to find Boost in the first place.
 Any ideas?

 Peter
>
>

-
-- 
Peter Steinbach, Dr. rer. nat.
HPC Developer

Scionics Computer Innovation GmbH
Löscherstr. 16
01309 Dresden
fon: +49 351 210 2882
fax: +49 351 210 1689
http://www.scionics.de

Sitz der Gesellschaft:  Dresden (Main office)
Amtsgericht - Registergericht:  Dresden HRB 20337 (Commercial Registry)
Ust-IdNr.:  DE813263791 (VAT ID Number)
Geschäftsführer:  John Duperon, Jeff Oegema (Managing Directors)
-- 

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-developers] [CMake 0015833]: Support creating of Framework for iOS

2015-11-05 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15833 
== 
Reported By:gang65
Assigned To:
== 
Project:CMake
Issue ID:   15833
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-11-05 11:29 EST
Last Modified:  2015-11-05 11:29 EST
== 
Summary:Support creating of Framework for iOS
Description: 
The framework from Apple is specific directory structure. 

For OS X it is using versioned directory structue.
The directory structure looks like:
MyFramework.framework/
MyFramework  -> Versions/Current/MyFramework
Resources-> Versions/Current/Resources
Versions/
A/
MyFramework
Headers
Resources/
English.lproj/
InfoPlist.strings
Info.plist
Current  -> A


More info:
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html#//apple_ref/doc/uid/20002253-BAJEJJAB


These structure is used when you specify following target variables:
set_target_properties(MyFramework PROPERTIES
  FRAMEWORK TRUE
  FRAMEWORK_VERSION A
  MACOSX_FRAMEWORK_IDENTIFIER com.cmake.myframework
)


For iOS the "flat" directory structure is used.
It looks like:
iOSFramework.framework/
  iOSFramework
  Info.plist
  Headers
  Resources/
English.lproj/
 InfoPlist.strings

Currently it is not possible to create "flat" directory structure which could be
used for iOS.

Solution proposal:
Allow possibility to create "flat" framework.
The flat framework will be produced when  IOS_FRAMEWORK will be set to TRUE
For example:

set_target_properties(MyFramework PROPERTIES
  IOS_FRAMEWORK TRUE
  MACOSX_FRAMEWORK_IDENTIFIER com.cmake.myframework
)

I would like to implement that, and provide patches to cmake.
I need some architectural support from you.




Additional Information: 
Maybe also I could fix:
https://public.kitware.com/Bug/view.php?id=15820
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-05 11:29 gang65 New 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


[cmake-developers] [CMake 0015834]: problem with buliding Deformable Model Simplex Mesh

2015-11-05 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://www.itk.org/Bug/view.php?id=15834 
== 
Reported By:Evan samona
Assigned To:
== 
Project:CMake
Issue ID:   15834
Category:   CCMake
Reproducibility:sometimes
Severity:   minor
Priority:   immediate
Status: new
== 
Date Submitted: 2015-11-05 13:36 EST
Last Modified:  2015-11-05 13:36 EST
== 
Summary:problem with buliding Deformable Model Simplex Mesh
Description: 
Hello, I am trying to build the  Deformable Model Simplex Mesh but when I run
the CCmake 

I got the following errors 


 CMake Error: Error required internal CMake variable not set, cmake may be not
 be built correctly.
 Missing variable is:
 FLTK_FLUID_EXECUTABLE

 CMake Error at CMakeLists.txt:58 (ITK_DISABLE_FLTK_GENERATED_WARNINGS):
   Unknown CMake command "ITK_DISABLE_FLTK_GENERATED_WARNINGS".



 FLTK_WRAP_UI was called with a target that was never created:
 DeformableModelSimplexMesh.  The problem was found while processing the
 source directory: /home/itk/itk-dev/ITKApps/DeformableModelSimplexMesh.  This
 FLTK_WRAP_UI call will be ignored.



== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-05 13:36 Evan samonaNew 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


[CMake] Question about the "logic" behind Utilities/KWIML/INT.h.in statement: @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_intptr_t, sizeof(void*));

2015-11-05 Thread Custin, Jay (CSC Sw Middleware)
>From INT.h.in:

   828  #if !defined(@KWIML@_INT_NO_INTPTR_T)
   829  @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_intptr_t,  sizeof(void*));
   830  #endif
   831  #if !defined(@KWIML@_INT_NO_UINTPTR_T)
   832  @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_uintptr_t, sizeof(void*));
   833  #endif

Now this statement blows up in the make Makefile process as follows:


cmIML_INT__VERIFY_TYPE(cmIML_INT_intptr_t,  sizeof(void*));
^
%CXX-E-NOTCOMPREDEC, declaration is incompatible with
  "int (*cmIML_INT_intptr_t__VERIFY__)[4U]" (declared at line 829)
at line number 829 in file LCL_ROOT:[cmake-3_3_2.Bootstrap_cmk.cmIML]INT.h;11



I wrote a simple C application to confirm the compiler's values, 
compiled-and-linked the application on both OpenVMS and Fedora Linux (x64) and 
noticed a discrepancy... 

ITAN1* ty foo.c
#include 
#include 
#include 
int main(void) {

   printf( "sizeof(intptr_t) = %d\n", sizeof(intptr_t));
   printf( "sizeof(uintptr_t) = %d\n", sizeof(uintptr_t));
   printf( "sizeof(void *) = %d\n", sizeof(void *));

   return EXIT_SUCCESS;
}


On OpenVMS this application displays the following:

ITAN1* r foo
sizeof(intptr_t) = 8
sizeof(uintptr_t) = 8
sizeof(void *) = 4 
sizeof(int *) = 4

and clearly sizeof(void *) = 4  < does NOT equal >  sizeof(intptr_t) = 8

On Fedora22 the exact same application displays the following:

[jpcustin@localhost ~]$ ./foo
sizeof(intptr_t) = 8
sizeof(uintptr_t) = 8
sizeof(void *) = 8 
sizeof(int *) = 8
[jpcustin@localhost ~]$


http://en.cppreference.com/w/c/types/integer describes intptr_t as: "integer 
type capable of holding a pointer"

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html goes a 
little further:

Integer types capable of holding object pointers

The following type designates a signed integer type with the property that any 
valid pointer to void can be converted to this type, then converted back to a 
pointer to void, and the result will compare equal to the original pointer: 
intptr_t

The following type designates an unsigned integer type with the property that 
any valid pointer to void can be converted to this type, then converted back to 
a pointer to void, and the result will compare equal to the original pointer: 
uintptr_t


This begs the question...

Why does the CMake test rely on checking if sizeof(intptr_t) equals sizeof(void 
*) 

instead of sizeof(intptr_t) greater than or equal to sizeof(void *) 

(so can an intptr_t "hold" a void *)?

JayC
-- 

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


Re: [CMake] Question about the "logic" behind Utilities/KWIML/INT.h.in statement: @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_intptr_t, sizeof(void*));

2015-11-05 Thread Custin, Jay (CSC Sw Middleware)
Probably a moot question at this point... I posed the same question to some of 
the language/compiler experts at HPE and got the following explanation:

Looking quickly, I suspect that he is not using the /pointer=long qualifier at 
compile time.
The default pointer size is 32-bit (4 bytes), but there are a few different 
ways to get 64-bit pointers.  The /pointer=long is the easiest.
Hope this helps.

05>hpcc/pointer=long ptr_test
05>link ptr_test
05>r ptr_test
sizeof(intptr_t) = 8
sizeof(uintptr_t) = 8
sizeof(void *) = 8
sizeof(int *) = 8
05>


-Original Message-
From: Custin, Jay (CSC Sw Middleware) 
Sent: Thursday, November 05, 2015 1:28 PM
To: cmake@cmake.org
Subject: Question about the "logic" behind Utilities/KWIML/INT.h.in statement: 
@KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_intptr_t, sizeof(void*));

>From INT.h.in:

   828  #if !defined(@KWIML@_INT_NO_INTPTR_T)
   829  @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_intptr_t,  sizeof(void*));
   830  #endif
   831  #if !defined(@KWIML@_INT_NO_UINTPTR_T)
   832  @KWIML@_INT__VERIFY_TYPE(@KWIML@_INT_uintptr_t, sizeof(void*));
   833  #endif

Now this statement blows up in the make Makefile process as follows:


cmIML_INT__VERIFY_TYPE(cmIML_INT_intptr_t,  sizeof(void*)); ^ 
%CXX-E-NOTCOMPREDEC, declaration is incompatible with
  "int (*cmIML_INT_intptr_t__VERIFY__)[4U]" (declared at line 829) at 
line number 829 in file LCL_ROOT:[cmake-3_3_2.Bootstrap_cmk.cmIML]INT.h;11



I wrote a simple C application to confirm the compiler's values, 
compiled-and-linked the application on both OpenVMS and Fedora Linux (x64) and 
noticed a discrepancy... 

ITAN1* ty foo.c
#include 
#include 
#include 
int main(void) {

   printf( "sizeof(intptr_t) = %d\n", sizeof(intptr_t));
   printf( "sizeof(uintptr_t) = %d\n", sizeof(uintptr_t));
   printf( "sizeof(void *) = %d\n", sizeof(void *));

   return EXIT_SUCCESS;
}


On OpenVMS this application displays the following:

ITAN1* r foo
sizeof(intptr_t) = 8
sizeof(uintptr_t) = 8
sizeof(void *) = 4
sizeof(int *) = 4

and clearly sizeof(void *) = 4  < does NOT equal >  sizeof(intptr_t) = 8

On Fedora22 the exact same application displays the following:

[jpcustin@localhost ~]$ ./foo
sizeof(intptr_t) = 8
sizeof(uintptr_t) = 8
sizeof(void *) = 8
sizeof(int *) = 8
[jpcustin@localhost ~]$


http://en.cppreference.com/w/c/types/integer describes intptr_t as: "integer 
type capable of holding a pointer"

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html goes a 
little further:

Integer types capable of holding object pointers

The following type designates a signed integer type with the property that any 
valid pointer to void can be converted to this type, then converted back to a 
pointer to void, and the result will compare equal to the original pointer: 
intptr_t

The following type designates an unsigned integer type with the property that 
any valid pointer to void can be converted to this type, then converted back to 
a pointer to void, and the result will compare equal to the original pointer: 
uintptr_t


This begs the question...

Why does the CMake test rely on checking if sizeof(intptr_t) equals sizeof(void 
*) 

instead of sizeof(intptr_t) greater than or equal to sizeof(void *) 

(so can an intptr_t "hold" a void *)?

JayC
-- 

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


[cmake-developers] [CMake 0015835]: CMake hardcodes bitness in .cmake files for universal binaries

2015-11-05 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15835 
== 
Reported By:David Ryskalczyk
Assigned To:
== 
Project:CMake
Issue ID:   15835
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   high
Status: new
== 
Date Submitted: 2015-11-05 16:44 EST
Last Modified:  2015-11-05 16:44 EST
== 
Summary:CMake hardcodes bitness in .cmake files for
universal binaries
Description: 
CMake currently hardcodes the bitness of a built package in the .cmake config
file. As Mac OS X supports universal binaries, where a package can be compiled
as both 32 and 64 bit, this is inaccurate, and causes problems when linking to
libraries built as universal using CMAKE_OSX_ARCHITECTURES.
This affects all versions of Mac OS X.

Steps to Reproduce: 
Build a library as a universal binary (using
-DCMAKE_OSX_ARCHITECTURES=x86_64;i386); then try compiling a program that uses
that library as either x86_64 or i386. One of them will work, the other will
not. If the Config .cmake file is opened in an editor, it is obvious that the
bitness is recorded and checked, based on the value of CMAKE_SIZEOF_VOID_P —
which is inaccurate when the binary is built as universal.

Additional Information: 
A better fix might be to store a list of architectures/bitness that the package
is built as, but I'm unsure of how to do this in CMake.

A patch is attached which simply ignores the bitness section of the config
.cmake files when building on OS X.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-05 16:44 David RyskalczykNew Issue
2015-11-05 16:44 David RyskalczykFile Added: cmake-osx-universal-patch.diff 
  
==

-- 

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] autouic problem with Visual Studio

2015-11-05 Thread clinton
Hi, 

I'm trying out the autouic feature in Visual Studio, and I noticed that if I 
change a .ui file, the corresponding ui_*.h file is not regenerated when I hit 
the build button. 
I don't see this problem under Makefiles. 

For makefiles, it appears a phony target is used and "cmake -E cmake_autogen" 
is always run each time make is called. 
For visual studio, the build rule to execute "cmake -E cmake_autogen" has a 
list of dependencies. This list of dependencies includes all the files listed 
in a .qrc file, but none of the .ui files. If I right click on the file 
representing this build rule, and click "compile", it then runs "cmake -E 
cmake_autogen" and the ui_*.h files are incrementally updated (only those for 
which corresponding .ui files were changed). 

This appears to be a bug. The setup is different between the two, and perhaps 
the build rule under visual studio should list all the dependent .ui files. 

Is anyone else seeing this behavior? 

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

[CMake] Problems with cmake in Windows related to maximum path length

2015-11-05 Thread Hauke Krüger
Hi everybody,

I am a new user of cmake and a new member of this mailing list.
Apologies in case the reason for my problem is the fact that I am not
experienced with using cmake.

I use cmake to generate "nmake Makefiles" in Windows (Visual Studio
compiler). The project is rather large, hence, I tend to run into max
path limitation problems.
I have understood that I should not run into these problems since the
hashing of the paths is intended to cope with most of these problems.

I have then downloaded the latest version of the cmake source code and
found the reason for this problem:

Let us assume we have defined a project XX which defines two targets
1) "XX"
2) "XX_variant1_with_modification_a"

which, e.g., are shared libraries.

I use  very long path names and run into the system maximum path
limitations. I understood that the maximum path length is 250 on Windows
and leads to the shortened version of the object paths in case the path
turns out to be too large. The shortening is based on the MD5 hashing
mechanism.

I found that the object filename shortening happens in file
"cmLocalGenerator.cxx". In that function, all object file lengths are
checked against the maximum path
length given. The function declaration is "bool
cmLocalGeneratorCheckObjectName(std::string& objName,
std::string::size_type dir_len, std::string::size_type max_total_len)",
the object file path is characterized by the "dir_len" and the
"objName", the path limitation is specified by "max_total_len".

In the path length comparison, the "dir_len" value comes from an
evaluation of the variable "dir_max" which originates from
a function called void
"cmLocalUnixMakefileGenerator3::ComputeObjectFilenames(std::map& mapping,cmGeneratorTarget const* gt)
in  "cmLocalUnixMakefileGenerator3.cpp" (involving functions
"CreateSafeUniqueObjectFileName" and "GetObjectFileNameWithoutTarget").

As far as I understood, the variable "dir_max" and with it value of
"dir_len" are incorrect: Coming back to our situation with the two
targets which
are derived from the project name, cmake generates object files in
subfolders of "/CMakeFiles/XX.dir" and
"/CMakeFiles/XX_variant1_with_modification_a.dir". In the
function "cmLocalGeneratorCheckObjectName",
however, the variable "dir_len" is related to a value of "dir_max" which
corresponds to the "/CMakeFiles/XX.dir".
This is not the maximum directory length as would be expected: In my
opinion, the value of "dir_max" should be
"/CMakeFiles/XX_variant1_with_modification_a.dir"!

If an object filename meets the constraints given the directory
"/CMakeFiles/XX.dir" to not cause the filename shortening,
it may happen that the path is too long for the directory
"/CMakeFiles/XX_variant1_with_modification_a.dir".
In the current implementation, the hashing/shortening mechanism is not
triggered, the resulting object file name path is longer than 250 and
I see a hard-to-understand build error.

The conclusion: the variable "dir_max" does not really contain the
maximum length directory name given all targets but only the directory
name of the first target or the project name - i did not follow this in
detail. My solution to overcome this problem currently: I set the
CMAKE_OBJECT_PATH_MAX  value to a value lower than 250, e.g., 

set(CMAKE_OBJECT_PATH_MAX 240)

in order to take into account that the maximum target path directory
length is by maximum 10 larger than the project directory path.

Does anyone else have an opinion on this? Or am I doing something in a
forbidden way?

Thank you for any comment and best regards

Hauke

-- 

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


[Cmake-commits] CMake branch, master, updated. v3.4.0-rc3-476-g13dc7bd

2015-11-05 Thread Kitware Robot
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  13dc7bdb5e3a0eaaf3607b154bba77a01404a788 (commit)
  from  60cbd9b9da2059481e2f29fbb5859a5b0643d3d7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=13dc7bdb5e3a0eaaf3607b154bba77a01404a788
commit 13dc7bdb5e3a0eaaf3607b154bba77a01404a788
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Nov 6 00:01:05 2015 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Nov 6 00:01:05 2015 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index b93e0c9..62142c6 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 4)
-set(CMake_VERSION_PATCH 20151105)
+set(CMake_VERSION_PATCH 20151106)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits


[cmake-developers] [CMake 0015836]: Cmake Build Fails for cmake 3.1 version

2015-11-05 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15836 
== 
Reported By:Abdul Naseer
Assigned To:
== 
Project:CMake
Issue ID:   15836
Category:   CMake
Reproducibility:always
Severity:   block
Priority:   immediate
Status: new
== 
Date Submitted: 2015-11-06 01:26 EST
Last Modified:  2015-11-06 01:26 EST
== 
Summary:Cmake Build Fails for cmake 3.1 version
Description: 
I have tried to build the package cmake 3.1
I used below commands to build the package and install it

[root@euca-10-254-99-245 cmake-3.1.0]# ./bootstrap
--prefix=/apps/public/cmake_3.1/ --system-libs --no-system-jsoncpp
--mandir=/share/man
this above command is successfully completed.

But when i go for the second command ( gmake command) it fails at some point (
at 31%-fails)

[root@euca-10-254-169-217 cmake-3.1.0]# gmake
[  3%] Built target cmIML_test
[  9%] Built target cmsys
[  9%] Built target cmsysTestDynload
[ 12%] Built target cmsys_c
[ 12%] Built target cmsysTestProcess
[ 13%] Built target cmsysTestSharedForward
[ 14%] Built target cmsysTestsC
[ 17%] Built target cmsysTestsCxx
[ 18%] Built target cmcompress
[ 31%] Built target cmForm
[ 31%] Building CXX object Source/CMakeFiles/CMakeLib.dir/cmArchiveWrite.cxx.o
/ephemeral/abdnasee/cmake/cmake-3.1.0/Source/cmArchiveWrite.cxx: In function
âvoid cm_archive_entry_copy_sourcepath(archive_entry*, const std::string&)â:
/ephemeral/abdnasee/cmake/cmake-3.1.0/Source/cmArchiveWrite.cxx:43: error:
âarchive_entry_copy_sourcepath_wâ was not declared in this scope
/ephemeral/abdnasee/cmake/cmake-3.1.0/Source/cmArchiveWrite.cxx: In constructor
âcmArchiveWrite::cmArchiveWrite(std::ostream&, cmArchiveWrite::Compress,
cmArchiveWrite::Type)â:
/ephemeral/abdnasee/cmake/cmake-3.1.0/Source/cmArchiveWrite.cxx:164: error:
âarchive_write_set_format_7zipâ was not declared in this scope
gmake[2]: *** [Source/CMakeFiles/CMakeLib.dir/cmArchiveWrite.cxx.o] Error 1
gmake[1]: *** [Source/CMakeFiles/CMakeLib.dir/all] Error 2
gmake: *** [all] Error 2



Steps to Reproduce: 
You can simply download one tar file of cmake 3.1 and untar it 
and do the build using below commands



Additional Information: 
When i am using the first command ( ./bootstrap --prefix=/apps/public/cmake_3.1/
--system-libs --no-system-jsoncpp --mandir=/share/man)  without the options
--system-libs, the build get successful, but then there wont be any lib files
inside the installed path.

Is this a bug or do i need to install any packages extra. I have installed all
the required dependencies.


== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-11-06 01:26 Abdul Naseer   New Issue
2015-11-06 01:26 Abdul Naseer   File Added: Cmake error.JPG
==

-- 

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] [CDash] CTEST_CUSTOM_WARNING_EXECPTION

2015-11-05 Thread David Cole via CMake
Looks to me like it might be (I'm hopeful) working at ignoring the
line which matches the expression ".*vcl_deprecated_header.h.*" ...

But then, the following line is:

 # warning "deprecated"

Since that line does not match any of your expressions, maybe that's
the one triggering this warning slipping through as unignored?


HTH,
D




On Thu, Nov 5, 2015 at 10:01 AM, Rashad M  wrote:
> yes.
>
> On Thu, Nov 5, 2015 at 1:46 PM, David Cole  wrote:
>>
>> Does your ctest -S script call ctest_read_custom_files
>> https://cmake.org/cmake/help/v3.4/command/ctest_read_custom_files.html after
>> ctest_configure?
>>
>>
>> On Thursday, November 5, 2015, Rashad M 
>> wrote:
>>>
>>> Hello all,
>>>
>>> I have CTestCustom.cmake.in file in source tree with the following
>>> contents
>>>
>>>
>>> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in
>>>
>>> during ctest build CTestCustom.cmake file is getting generated inside the
>>> build tree.
>>>
>>> But however the warnings are not filtered out on the dashboard. For
>>> instance, see the dashboard submission
>>> http://dash.orfeo-toolbox.org/viewBuildError.php?type=1=206112
>>>
>>> and see the exception for vcl_deprecated_header
>>>
>>>
>>> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69
>>>
>>> The warning appears on dashobard anyway. Can someone point me in the
>>> right direction. ?
>>>
>>> Thanks in advance.
>>>
>>>
>>> CMake Version:
>>> 2.8.12.2
>>>
>>> CDash Version:
>>> 2.2.3
>>>
>>> uname -a
>>> Linux ubuntu
>>>
>>>  3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64
>>> x86_64 x86_64 GNU/Linux
>>> --
>>> Regards,
>>>Rashad
>
>
>
>
> --
> Regards,
>Rashad
-- 

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


Re: [CMake] [CDash] CTEST_CUSTOM_WARNING_EXECPTION

2015-11-05 Thread Rashad M
yes.

On Thu, Nov 5, 2015 at 1:46 PM, David Cole  wrote:

> Does your ctest -S script call ctest_read_custom_files
> https://cmake.org/cmake/help/v3.4/command/ctest_read_custom_files.html
> after ctest_configure?
>
>
> On Thursday, November 5, 2015, Rashad M 
> wrote:
>
>> Hello all,
>>
>> I have CTestCustom.cmake.in file in source tree with the following
>> contents
>>
>>
>> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in
>>
>> during ctest build CTestCustom.cmake file is getting generated inside the
>> build tree.
>>
>> But however the warnings are not filtered out on the dashboard. For
>> instance, see the dashboard submission
>> http://dash.orfeo-toolbox.org/viewBuildError.php?type=1=206112
>>
>> and see the exception for vcl_deprecated_header
>>
>>
>> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69
>>
>> The warning appears on dashobard anyway. Can someone point me in the
>> right direction. ?
>>
>> Thanks in advance.
>>
>>
>> CMake Version:
>> 2.8.12.2
>>
>> CDash Version:
>> 2.2.3
>>
>> uname -a
>> Linux ubuntu
>>
>>  3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64
>> x86_64 x86_64 GNU/Linux
>> --
>> Regards,
>>Rashad
>>
>


-- 
Regards,
   Rashad
-- 

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

Re: [CMake] cmake needs 2 runs to find boost

2015-11-05 Thread Peter Steinbach
Hi to all,

ok, I tried the attached minimal CMakeLists.txt again and found out that it 
fails in the way I described only with the "MSYS Makefiles" generator. If I 
use the same CMakeLists.txt without a custom generator (so MSVS is the default 
IIRC), the libraries are found alright! 

Any ideas?
Best,
Peter

On Thursday, November 05, 2015 01:41:33 PM Peter Steinbach wrote:
> Hi Benedikt,
> 
> interesting thought, however I wonder why cmake is then capable of deducing
> the right boost version and include path. Just inside the first error
> message, I see:
> 
> (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message):
> > >Unable to find the requested Boost libraries.
> > >
> > >Boost version: 1.57.0
> > >
> > >Boost include path: C:/msys64/mingw64/include
> > >
> > >Could not find the following static Boost libraries:
> > >boost_filesystem
> > >boost_system
> 
> strange, isn't it?
> Peter
> 
> On Thursday, November 05, 2015 11:41:10 AM Benedikt Hegner wrote:
> > Hi Peter,
> > 
> > as I don't use windows at all, this is just a very wild guess...
> > 
> > Could it be that in the second run you actually don't use
> > 
> >/CMake/share/cmake-3.2/Modules/FindBoost.cmake
> > 
> > but boost-config.cmake, which it now finds in the cached environment of
> > the first run?
> > 
> > This assumes of course that you built boost w/ CMake and not bjam...
> > 
> > Cheers,
> > 
> >Benedikt
> > 
> > On 03.11.2015 14:10, Peter Steinbach wrote:
> > > Hi to all,
> > > 
> > > I tested this with cmake 3.2.2 and 3.3.2 and still get the same problem.
> > > I'd like to use boost with gcc on windows 7 64bit. I installed boost and
> > > gcc with msys2 as I cannot use MSVC for the actual project I am looking
> > > into for this.
> > > 
> > > the funny thing, if I use the attached CMakeLists.txt on the machine and
> > > call: ```
> > > $ cmake -G "MSYS Makefiles" -DBOOST_ROOT=C:/msys64/mingw64 -
> > > DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib ..
> > > -- The CXX compiler identification is GNU 4.9.2
> > > -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe
> > > -- Check for working CXX compiler: C:/msys64/usr/bin/g++.exe -- works
> > > -- Detecting CXX compiler ABI info
> > > -- Detecting CXX compiler ABI info - done
> > > -- Detecting CXX compile features
> > > -- Detecting CXX compile features - done
> > > setting win specific stuff
> > > CMake Error at C:/Program Files
> > > 
> > > (x86)/CMake/share/cmake-3.2/Modules/FindBoost.cmake:1182 (message):
> > >Unable to find the requested Boost libraries.
> > >
> > >Boost version: 1.57.0
> > >
> > >Boost include path: C:/msys64/mingw64/include
> > >
> > >Could not find the following static Boost libraries:
> > >boost_filesystem
> > >boost_system
> > >
> > >No Boost libraries were found.  You may need to set BOOST_LIBRARYDIR
> > >to
> > >the
> > >directory containing Boost libraries or BOOST_ROOT to the location of
> > >Boost.
> > > 
> > > Call Stack (most recent call first):
> > >CMakeLists.txt:17 (FIND_PACKAGE)
> > > 
> > > CMake Error at CMakeLists.txt:24 (MESSAGE):
> > >Boost not found (C:/msys64/mingw64)
> > > 
> > > -- Configuring incomplete, errors occurred!
> > > See also
> > > "C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build/CMak
> > > eF
> > > iles/CMakeOutput.log". $ cmake -G "MSYS Makefiles"
> > > -DBOOST_ROOT=C:/msys64/mingw64 -
> > > DBOOST_LIBRARYDIR==C:/msys64/mingw64/lib ..
> > > setting win specific stuff
> > > Boost 1.57 found __
> > > -- Configuring done
> > > -- Generating done
> > > -- Build files have been written to:
> > > C:/msys64/home/steinbac/development/cmake_sandbox/find_boost/build
> > > ```
> > > 
> > > I'd like to link statically to multithreaded libboost_*-mt.a from my
> > > app.
> > > But it proofes really hard to find Boost in the first place.
> > > Any ideas?
> > > 
> > > Peter

-- 
Peter Steinbach, Dr. rer. nat.
HPC Developer

Scionics Computer Innovation GmbH
Löscherstr. 16
01309 Dresden
fon: +49 351 210 2882
fax: +49 351 210 1689
http://www.scionics.de

Sitz der Gesellschaft:  Dresden (Main office)
Amtsgericht - Registergericht:  Dresden HRB 20337 (Commercial Registry)
Ust-IdNr.:  DE813263791 (VAT ID Number)
Geschäftsführer:  John Duperon, Jeff Oegema (Managing Directors)# cmake compatibility issues
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

# project name
PROJECT(test CXX)

set(Boost_USE_STATIC_LIBSON)

IF(WIN32)
MESSAGE("setting win specific stuff")
set(Boost_USE_MULTITHREADED  ON)
set(Boost_USE_STATIC_RUNTIME OFF)
set(BOOST_ALL_DYN_LINK   OFF)
#set(Boost_ADDITIONAL_VERSIONS "1.47" "1.47.0")

ENDIF()
FIND_PACKAGE (Boost 1.42 QUIET COMPONENTS filesystem system REQUIRED)

IF(Boost_FOUND)
MESSAGE("Boost ${Boost_MAJOR_VERSION}.${Boost_MINOR_VERSION} found _${Boost_LIBRARIES}_")

ELSE()

MESSAGE(FATAL_ERROR "Boost not found (${BOOST_ROOT})")
IF(NOT EXISTS 

Re: [cmake-developers] [PATCH 0/3] Support for multilingual SLAs for the CPack DMG generator

2015-11-05 Thread Levermann, Simon
The documentation files had incorrect file extensions. This is fixed in
the attached version.

On Do, 2015-11-05 at 10:36 +, Levermann, Simon wrote:
> Hi Brad,
> 
> the attached patch limits lines to 79 cols, and adds the necessary
> documentation to the variables and release notes.
> 
> I added diagnostic pragmas to suppress the deprecation warnings as
> well
> as a comment explaining the need for them. I've looked for a
> replacement some more, but I still haven't been able to find
> anything.
> I could try to hard-code it by writing a simple program that iterates
> all possible language codes (it's "only" a 16-bit value, so 2^16
> combinations). However, this feels even hackier to me than the
> current
> state.
> 
> This patch is a single commit rebased on current master
> (60cbd9b9da2059481e2f29fbb5859a5b0643d3d7)
> 
> Kind regards,
> Simon
> 
> On Mi, 2015-11-04 at 10:46 -0500, Brad King wrote:
> > On 11/03/2015 06:09 AM, Levermann, Simon wrote:
> > > This adds support for multilingual SLAs which are displayed when
> > > the user is trying to mount the DMG.
> > 
> > Thanks for working on this and for bringing the patch to this list.
> > 
> > Patches 2 and 3 look like fixups.  Please squash that all into one
> > commit.  Also please keep C++ sources wrapped to 79 columns or
> > less.
> > 
> > > Multiple languages can be added via the new variables
> > > CPACK_DMG_SLA_DIR
> > > and CPACK_DMG_SLA_LANGUAGES.
> > 
> > Please add Help/variable/*.rst files to document these.  Also
> > please add a Help/release/dev/*.rst file to add a release note
> > for the feature.
> > 
> > > For each language defined, CPack will search for a
> > > language.menu.txt
> > > and language.license.txt file in CPACK_SLA_DIR.
> > 
> > Good.  Please mention this in the above-requested documentation.
> > 
> > > This patch adds a library to the deprecated Carbon Framework to
> > > CPackLib, since the functions/types required to acquire the
> > > region
> > > code for the internal LPic data structure are only available in
> > > this
> > > old API. Apple does not seem to be offering a replacement API for
> > > the
> > > old ScriptManager region codes.
> > 
> > Hopefully an alternative can be found.  Meanwhile I get warnings
> > during the build due to
> > DEPRECATED_IN_MAC_OS_X_VERSION_10_6_AND_LATER
> > appearing on the declarations of these APIs.  Please add pragmas
> > or whatever is needed to suppress them, at least with Clang.  Call
> > out the purpose for the suppression with a comment explaining why
> > we need to use the deprecated APIs.
> > 
> > > Additional thought: One could add the language.menu.txt files for
> > > some common languages to the repository.
> > 
> > Let's defer that until the actual feature is working.
> > 
> > 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-developersFrom 8191397c2da9d0698b37b86ddc1c2ca69bc48c72 Mon Sep 17 00:00:00 2001
From: Simon Levermann 
Date: Mon, 19 Oct 2015 11:13:55 +0200
Subject: [PATCH] Add support for multilingual SLAs

Multiple languages for SLAs and the SLA UI can be added via the CPack variables
CPACK_DMG_SLA_DIR and CPACK_DMG_SLA_LANGUAGES. For each language defined in the
languages variable, CPack will search for .menu.txt and
.license.txt in CPACK_DMG_SLA_DIR. If the sla directory variable is not
defined, the old behaviour using CPACK_RESOURCE_FILE_LICENSE is retained

Pass string by const& instead of copying

Remove superfluous assignment

Add deprecation pragma and comment

Break lines longer than 79 characters

Add variable documentation for new CPACK_DMG_ variables

Add release note for multilanguage-sla
---
 Help/release/dev/cpack-dmg-multilanguage-sla.rst |   6 +
 Help/variable/CPACK_DMG_SLA_DIR.rst  |   6 +
 Help/variable/CPACK_DMG_SLA_LANGUAGES.rst|   6 +
 Source/CMakeLists.txt|   4 +
 Source/CPack/cmCPackDragNDropGenerator.cxx   | 357 ---
 Source/CPack/cmCPackDragNDropGenerator.h |  10 +
 6 files changed, 351 insertions(+), 38 deletions(-)
 create mode 100644 Help/release/dev/cpack-dmg-multilanguage-sla.rst
 create mode 100644 Help/variable/CPACK_DMG_SLA_DIR.rst
 create mode 100644 Help/variable/CPACK_DMG_SLA_LANGUAGES.rst

diff --git a/Help/release/dev/cpack-dmg-multilanguage-sla.rst b/Help/release/dev/cpack-dmg-multilanguage-sla.rst
new