Re: [cmake-developers] [PATCH] Avoid bad alloc for large files
Am Montag, 22. Dezember 2014, 22:16:50 schrieb Rolf Eike Beer: Am Montag, 22. Dezember 2014, 10:50:28 schrieb Brad King: On 12/20/2014 08:44 AM, Rolf Eike Beer wrote: This is basically the same, but it avoids the needless floating point arithmetic. Does it work for you? Thanks, Eike. Please add a topic to put this in 'next' when ready. Done. I wonder if we should not check for new returning null? Ok, now I get this: cmCTest.cxx C:\Dashboards\My Tests\CMakeNext-vs12-64-ninja-src\Source\cmCTest.cxx(1705) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned long', possible loss of data The problem is: this is absolutely right. On Windows64 this means that the maximum file size will be 4GB, or one needs to change the base64 implementation. Which way to go? Eike signature.asc Description: This is a digitally signed message part. -- 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] Avoid bad alloc for large files
Am Dienstag, 23. Dezember 2014, 10:27:47 schrieb Rolf Eike Beer: Am Montag, 22. Dezember 2014, 22:16:50 schrieb Rolf Eike Beer: Am Montag, 22. Dezember 2014, 10:50:28 schrieb Brad King: On 12/20/2014 08:44 AM, Rolf Eike Beer wrote: This is basically the same, but it avoids the needless floating point arithmetic. Does it work for you? Thanks, Eike. Please add a topic to put this in 'next' when ready. Done. I wonder if we should not check for new returning null? Ok, now I get this: cmCTest.cxx C:\Dashboards\My Tests\CMakeNext-vs12-64-ninja-src\Source\cmCTest.cxx(1705) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned long', possible loss of data The problem is: this is absolutely right. On Windows64 this means that the maximum file size will be 4GB, or one needs to change the base64 implementation. Which way to go? *lol* From: Brad King (Code Review) rev...@kitware.com Date: Tue, 23 Dec 2014 04:27:55 -0500 Subject: Change in KWSys[master]: Base64: Use size_t for lenghts in API signature.asc Description: This is a digitally signed message part. -- 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] Avoid bad alloc for large files
On 12/23/2014 4:27 AM, Rolf Eike Beer wrote: cmCTest.cxx C:\Dashboards\My Tests\CMakeNext-vs12-64-ninja-src\Source\cmCTest.cxx(1705) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned long', possible loss of data The problem is: this is absolutely right. On Windows64 this means that the maximum file size will be 4GB, or one needs to change the base64 implementation. Which way to go? The KWSys Base64 API should be fixed to use size_t: http://review.source.kitware.com/18579 Domen's suggestion elsewhere in this thread of using a streaming implementation will be necessary to support large files on 32-bit platforms. That can be done as follow-up work though. -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] Which binaries should be required in FindLATEX?
On 12/22/2014 6:29 PM, Christoph Grüninger wrote: please find attached a new patch following your latest suggestions. Thanks. I'd like to have lower case components but I dislike mixed-cased variable names. The latter feeling is stronger. Mixed-case variable names are quite common in CMake APIs, especially when dealing with components like this, but I don't have a strong feeling either way on this. However, the _FOUND variables are not cache entries so they do not need to appear in mark_as_advanced. -find_package_handle_standard_args(Latex +find_package_handle_standard_args(LATEX Good catch. The capitalization should match the name of the find module. This was a mistake in the original FPHSA change for FindLATEX. 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] Introducing targets in FindPkgConfig
On 22/12/14 19:38, Rolf Eike Beer wrote: About the FindPkgConfig macros documentation, what is that is not clear? It's not about the documentation of that module, but where I need to hack it into the module. The code is quite a bit of indirections, I guess I would need to do this _pkg_check_modules_internal at the end of the last foreach? Yes, I think that you can do it either in _pkg_check_modules_internal after the line 385 (unset(_pkgconfig_path_old)) right before the else(), or (perhaps better) in a new internal macro that you will call after the _pkgconfig_set line in pkg_search_module and pkg_check_modules. Cheers, Daniele -- 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] Which binaries should be required in FindLATEX?
Hi Brad,
next try and as always better than the last attempt.
Bye
Christoph
From ba775bd58b70ad2581fc05f30d8c5e42e1c94096 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christoph=20Gr=C3=BCninger?= gruen...@dune-project.org
Date: Tue, 23 Dec 2014 11:33:32 +0100
Subject: [PATCH] FindLATEX: Add components handling
---
Modules/FindLATEX.cmake | 78 +
1 file changed, 72 insertions(+), 6 deletions(-)
diff --git a/Modules/FindLATEX.cmake b/Modules/FindLATEX.cmake
index a935f00..28a7247 100644
--- a/Modules/FindLATEX.cmake
+++ b/Modules/FindLATEX.cmake
@@ -6,17 +6,42 @@
#
# This module finds an installed Latex and determines the location
# of the compiler. Additionally the module looks for Latex-related
-# software like BibTeX. This code sets the following variables:
+# software like BibTeX.
+#
+# This module sets the following result variables:
#
# ::
#
+# LATEX_FOUND: whether found Latex and requested components
+# LATEX_component_FOUND: whether found component
# LATEX_COMPILER: path to the LaTeX compiler
# PDFLATEX_COMPILER:path to the PdfLaTeX compiler
# BIBTEX_COMPILER: path to the BibTeX compiler
# MAKEINDEX_COMPILER: path to the MakeIndex compiler
# DVIPS_CONVERTER: path to the DVIPS converter
+# DVIPDF_CONVERTER: path to the DVIPDF converter
# PS2PDF_CONVERTER: path to the PS2PDF converter
# LATEX2HTML_CONVERTER: path to the LaTeX2Html converter
+#
+# Possible components are:
+#
+# ::
+#
+# PDFLATEX
+# BIBTEX
+# MAKEINDEX
+# DVIPS
+# DVIPDF
+# PS2PDF
+# LATEX2HTML
+#
+# Example Usages:
+#
+# ::
+#
+# find_package(LATEX)
+# find_package(LATEX COMPONENTS PDFLATEX)
+# find_package(LATEX COMPONENTS BIBTEX PS2PDF)
#=
# Copyright 2002-2014 Kitware, Inc.
@@ -32,9 +57,7 @@
# License text for the above reference.)
if (WIN32)
-
# Try to find the MikTex binary path (look for its package manager).
-
find_path(MIKTEX_BINARY_PATH mpm.exe
[HKEY_LOCAL_MACHINE\\SOFTWARE\\MiK\\MiKTeX\\CurrentVersion\\MiKTeX;Install Root]/miktex/bin
DOC
@@ -43,7 +66,6 @@ if (WIN32)
mark_as_advanced(MIKTEX_BINARY_PATH)
# Try to find the GhostScript binary path (look for gswin32).
-
get_filename_component(GHOSTSCRIPT_BINARY_PATH_FROM_REGISTERY_8_00
[HKEY_LOCAL_MACHINE\\SOFTWARE\\AFPL Ghostscript\\8.00;GS_DLL] PATH
)
@@ -64,45 +86,76 @@ if (WIN32)
DOC Path to the GhostScript library directory.
)
mark_as_advanced(GHOSTSCRIPT_LIBRARY_PATH)
-
endif ()
+# try to find Latex and the related programs
find_program(LATEX_COMPILER
NAMES latex
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+# find pdflatex
find_program(PDFLATEX_COMPILER
NAMES pdflatex
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+if (PDFLATEX_COMPILER)
+ set(LATEX_PDFLATEX_FOUND TRUE)
+else()
+ set(LATEX_PDFLATEX_FOUND FALSE)
+endif()
+# find bibtex
find_program(BIBTEX_COMPILER
NAMES bibtex
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+if (BIBTEX_COMPILER)
+ set(LATEX_BIBTEX_FOUND TRUE)
+else()
+ set(LATEX_BIBTEX_FOUND FALSE)
+endif()
+# find makeindex
find_program(MAKEINDEX_COMPILER
NAMES makeindex
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+if (MAKEINDEX_COMPILER)
+# set(LATEX_MAKEINDEX_FOUND TRUE)
+else()
+ set(LATEX_MAKEINDEX_FOUND FALSE)
+endif()
+# find dvips
find_program(DVIPS_CONVERTER
NAMES dvips
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+if (DVIPS_CONVERTER)
+ set(LATEX_DVIPS_FOUND TRUE)
+else()
+ set(LATEX_DVIPS_FOUND FALSE)
+endif()
+# find dvipdf
find_program(DVIPDF_CONVERTER
NAMES dvipdfm dvipdft dvipdf
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+if (DVIPDF_CONVERTER)
+ set(LATEX_DVIPDF_FOUND TRUE)
+else()
+ set(LATEX_DVIPDF_FOUND FALSE)
+endif()
+# find ps2pdf
if (WIN32)
find_program(PS2PDF_CONVERTER
NAMES ps2pdf14.bat ps2pdf14 ps2pdf
@@ -114,12 +167,23 @@ else ()
NAMES ps2pdf14 ps2pdf
)
endif ()
+if (PS2PDF_CONVERTER)
+ set(LATEX_PS2PDF_FOUND TRUE)
+else()
+ set(LATEX_PS2PDF_FOUND FALSE)
+endif()
+# find latex2html
find_program(LATEX2HTML_CONVERTER
NAMES latex2html
PATHS ${MIKTEX_BINARY_PATH}
/usr/bin
)
+if (LATEX2HTML_CONVERTER)
+ set(LATEX_LATEX2HTML_FOUND TRUE)
+else()
+ set(LATEX_LATEX2HTML_FOUND FALSE)
+endif()
mark_as_advanced(
@@ -133,7 +197,9 @@ mark_as_advanced(
LATEX2HTML_CONVERTER
)
+# handle variables for found Latex and its components
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
-find_package_handle_standard_args(Latex
+find_package_handle_standard_args(LATEX
REQUIRED_VARS LATEX_COMPILER
+ HANDLE_COMPONENTS
)
--
2.1.2
--
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
[cmake-developers] Separate components for library and .so link
Is there a way to separate components for a library with a SONAME and
the link?
For example if I do something like this:
add_library(foo ${foo_SRCS})
set_target_properties(foo PROPERTIES SOVERSION 1)
install(TARGETS foo
LIBRARY DESTINATION lib)
This will install
prefix/lib/libfoo.so.1
prefix/lib/libfoo.so - libfoo.so.1
When packaging (at least for Debian and derived distributions), the .so
link is considered part of the -dev package (and installed with the
header files), while the library is part of the library package.
Is there a way to separate these 2 components with just one install command?
As far as I understand, it is possible to install the target twice using
NAMELINK_SKIP and NAMELINK_ONLY, but that seems a bit too redundant to me...
install(TARGETS foo
LIBRARY DESTINATION lib COMPONENT library NAMELINK_SKIP)
install(TARGETS foo
LIBRARY DESTINATION lib COMPONENT devel NAMELINK_ONLY)
I think it would be nice to be able to do something like
install(TARGETS foo
LIBRARY DESTINATION lib COMPONENT library
NAMELINK_COMPONENT devel)
What do you think?
Cheers,
Daniele
--
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] [Patch] Get rid of C++ warnings
Dear CMake developers,
find attached two small patches that get rid of C++ warnings I get from
the current GCC 5 development build.
One patch removes semicolons after methods, the other uses unsigned ints
for version numbers to match the type of the sscanf string %u.
Bye
Christoph
From bcc6d27bdf781a51f3e60b35f0918ce4d503efab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christoph=20Gr=C3=BCninger?= gruen...@dune-project.org
Date: Tue, 23 Dec 2014 12:24:58 +0100
Subject: [PATCH 2/3] Remove superfluous semicolons after methods.
---
Source/CTest/cmParseDelphiCoverage.cxx | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Source/CTest/cmParseDelphiCoverage.cxx b/Source/CTest/cmParseDelphiCoverage.cxx
index 8e331b1..3afbfac 100644
--- a/Source/CTest/cmParseDelphiCoverage.cxx
+++ b/Source/CTest/cmParseDelphiCoverage.cxx
@@ -240,7 +240,7 @@ bool cmParseDelphiCoverage::LoadCoverageData(
}
}
return true;
- };
+ }
bool cmParseDelphiCoverage::ReadDelphiHTML(const char* file)
{
@@ -248,4 +248,4 @@ bool cmParseDelphiCoverage::ReadDelphiHTML(const char* file)
parser(this-CTest, this-Coverage);
parser.ParseFile(file);
return true;
- };
+ }
--
2.1.2
From e810b5f8e4a1288897c71f40a6ded20d4777fa97 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christoph=20Gr=C3=BCninger?= gruen...@dune-project.org
Date: Tue, 23 Dec 2014 13:33:35 +0100
Subject: [PATCH 3/3] use unsigned int for version numbers.
---
Source/cmCMakeMinimumRequired.cxx | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Source/cmCMakeMinimumRequired.cxx b/Source/cmCMakeMinimumRequired.cxx
index 58b61de..384e0a7 100644
--- a/Source/cmCMakeMinimumRequired.cxx
+++ b/Source/cmCMakeMinimumRequired.cxx
@@ -63,17 +63,17 @@ bool cmCMakeMinimumRequired
// Get the current version number.
- int current_major = cmVersion::GetMajorVersion();
- int current_minor = cmVersion::GetMinorVersion();
- int current_patch = cmVersion::GetPatchVersion();
- int current_tweak = cmVersion::GetTweakVersion();
+ unsigned int current_major = cmVersion::GetMajorVersion();
+ unsigned int current_minor = cmVersion::GetMinorVersion();
+ unsigned int current_patch = cmVersion::GetPatchVersion();
+ unsigned int current_tweak = cmVersion::GetTweakVersion();
// Parse at least two components of the version number.
// Use zero for those not specified.
- int required_major = 0;
- int required_minor = 0;
- int required_patch = 0;
- int required_tweak = 0;
+ unsigned int required_major = 0;
+ unsigned int required_minor = 0;
+ unsigned int required_patch = 0;
+ unsigned int required_tweak = 0;
if(sscanf(version_string.c_str(), %u.%u.%u.%u,
required_major, required_minor,
required_patch, required_tweak) 2)
--
2.1.2
--
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] DragNDrop: Easier custom dmg layouts
On 12/22/2014 02:15 PM, Robert Maynard wrote: If anyone has any questions or issues with this branch please tell me. I'd appreciate feedback on this from others with experience in OS X packaging. For reference, the commit drafts are: DragNDropGenerator background image now uses source file extension. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c8b9f50 DragNDropGenerator now places the background image file in a hidden folder. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7f55ac9 DragNDropGenerator now can run an apple script when making a package. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=309ffd8e DragNDropGenerator copies the background image after the dmg is created. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2dc198b2 DragNDropGenerator now manually computes the size of the temp dmg image. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dfb74f52 DragNDropGenerator Updated Documentation to include new variables. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76a39f7a CMake DragNDrop release now uses a custom background and script http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4549f8ef However, for now I had to revert it from 'next' because it does not work on OS X = 10.5. -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] Separate components for library and .so link
On 12/23/2014 06:24 AM, Daniele E. Domenichelli wrote: I think it would be nice to be able to do something like install(TARGETS foo LIBRARY DESTINATION lib COMPONENT library NAMELINK_COMPONENT devel) Yes, I think that would make sense. 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] Get rid of C++ warnings
On 12/23/2014 07:36 AM, Christoph Grüninger wrote: find attached two small patches that get rid of C++ warnings I get from the current GCC 5 development build. One patch removes semicolons after methods, the other uses unsigned ints for version numbers to match the type of the sscanf string %u. Applied, thanks: cmParseDelphiCoverage: Remove superfluous semicolons after methods http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a9ba381 cmCMakeMinimumRequired: Use unsigned int for version numbers http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=098fc4a8 -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] Which binaries should be required in FindLATEX?
On 12/23/2014 05:35 AM, Christoph Grüninger wrote: next try and as always better than the last attempt. Applied: FindLATEX: Add components handling http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07a3f9ad with minor documentation tweaks and one logic fix: -# set(LATEX_MAKEINDEX_FOUND TRUE) + set(LATEX_MAKEINDEX_FOUND TRUE) that looked left from local testing. 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] DragNDrop: Easier custom dmg layouts
This looks pretty reasonable to me. From Rob's initial email, I thought it sounded like there was some sort of backward compatibility problem, but looking through the code, it seems like everything should all work the same for projects that aren't changing. Was I misunderstanding about backwards compatibility, or am I missing something? And although I haven't built it or run it myself yet, I trust that if the DMG produced for CMake looks good, that people can model their own code after CMake's own code to achieve better looking DMG installers. Personally, I am stuck on what I consider to be a very old Mac right now. It's a mini from ~2007-2008, and it's stuck running 10.6. I use it only when I absolutely have to (i.e. for virtually nothing) because it's so much slower than other machines I use. My point with mentioning this at all is to encourage you to drop support entirely for 10.6 at this point. (i.e. -- put this topic back in 'next' and retire those old Macs... they're tired... :-) Nice work, Rob. Thanks, David C. On Tue, Dec 23, 2014 at 9:01 AM, Brad King brad.k...@kitware.com wrote: On 12/22/2014 02:15 PM, Robert Maynard wrote: If anyone has any questions or issues with this branch please tell me. I'd appreciate feedback on this from others with experience in OS X packaging. For reference, the commit drafts are: DragNDropGenerator background image now uses source file extension. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c8b9f50 DragNDropGenerator now places the background image file in a hidden folder. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7f55ac9 DragNDropGenerator now can run an apple script when making a package. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=309ffd8e DragNDropGenerator copies the background image after the dmg is created. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2dc198b2 DragNDropGenerator now manually computes the size of the temp dmg image. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dfb74f52 DragNDropGenerator Updated Documentation to include new variables. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76a39f7a CMake DragNDrop release now uses a custom background and script http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4549f8ef However, for now I had to revert it from 'next' because it does not work on OS X = 10.5. -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 -- 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
