[cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14317
==
Reported By:Fabian Saccilotto
Assigned To:
==
Project:CMake
Issue ID: 14317
Category: CMake
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2013-07-26 04:43 EDT
Last Modified: 2013-07-26 04:43 EDT
==
Summary:Configuration dependent install EXPORT
Description:
Commands
INSTALL(TARGETS ... EXPORT
INSTALL(EXPORT
Installing exported libraries to configuration dependent folder doesn't work at
the moment.
Because of the fact that *-targets-configuration.cmake files are generated
during execution of CMake for the library to export, they contain paths with
${BUILD_TYPE}. During the find_package() stage of the parent project this
variable will be empty and therefore an error occurs that the file can't be
found.
Extract from *-targets-debug.cmake
set_target_properties(sba PROPERTIES
IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG C
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG blas;lapack;f2c
IMPORTED_LOCATION_DEBUG ${_IMPORT_PREFIX}/1.6/lib/${BUILD_TYPE}/sba.lib
)
Steps to Reproduce:
Install a library to a configuration dependent folder and install the export.
See the following CMakeLists.txt snippet.
# Snippet from CMakeLists.txt ---
add_library(libname sources)
# Export for later reuse
set(PACKAGE_NAME packagename)
set(VERSION version)
# Make a directory for each config
install(TARGETS libname
EXPORT ${PACKAGE_NAME}-targets
RUNTIME DESTINATION ${VERSION}/bin/\${BUILD_TYPE} COMPONENT Runtime
LIBRARY DESTINATION ${VERSION}/lib/\${BUILD_TYPE} COMPONENT Runtime
ARCHIVE DESTINATION ${VERSION}/lib/\${BUILD_TYPE} COMPONENT Development}
)
configure_file(
${${PROJECT_NAME}_SOURCE_DIR}/${PACKAGE_NAME}-config.cmake.in
${${PROJECT_NAME}_BINARY_DIR}/${PACKAGE_NAME}-config.cmake
@ONLY
)
configure_file(
${${PROJECT_NAME}_SOURCE_DIR}/${PACKAGE_NAME}-config-version.cmake.in
${${PROJECT_NAME}_BINARY_DIR}/${PACKAGE_NAME}-config-version.cmake
@ONLY
)
install(FILES
${${PROJECT_NAME}_BINARY_DIR}/${PACKAGE_NAME}-config.cmake
${${PROJECT_NAME}_BINARY_DIR}/${PACKAGE_NAME}-config.cmake
DESTINATION ${VERSION}
)
install(EXPORT ${PACKAGE_NAME}-targets DESTINATION ${VERSION})
# *-config.cmake.in ---
# Import the targets
get_filename_component(SELF_DIR ${CMAKE_CURRENT_LIST_FILE} PATH)
include(${SELF_DIR}/@PACKAGE_NAME@-targets.cmake)
Additional Information:
My proposal to add this feature:
The ${BUILD_TYPE} Variable could be set in the *-targets-configuration.cmake
file during creation of the files as the configuration is known.
I implemented the code on the source of 2.8.11.2 tag of the git repository and
made a patch.
In cmExportFileGenerator::GenerateImportHeaderCode the BUILD_TYPE variable is
set if a configuration is available. This allows users to use that variable in
install paths.
//
void cmExportFileGenerator::GenerateImportHeaderCode(std::ostream os,
const char* config)
{
os #\n
# Generated CMake target import file;
if(config)
{
os for configuration \ config \.\n;
}
else
{
os .\n;
}
os #\n
\n;
this-GenerateImportConfigurationCode(os, config);
this-GenerateImportVersionCode(os);
}
//
void cmExportFileGenerator::GenerateImportConfigurationCode(std::ostream os,
const char* config)
{
// Store the used configuration, this will allow configuration dependent
// paths in multi-configuration environments
if(config)
{
os # Set configuration for use in paths.\n
set(BUILD_TYPE config )\n
\n;
}
}
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-26 04:43 Fabian SaccilottoNew Issue
2013-07-26 04:43 Fabian SaccilottoFile Added:
Re: [cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies
On Wed, Jul 24, 2013 at 7:56 PM, Nicolas Desprès nicolas.desp...@gmail.comwrote: On Wed, Jul 24, 2013 at 12:18 PM, Stephen Kelly steve...@gmail.comwrote: Nicolas Desprès wrote: That's said we can optimize further as I mentioned in my comment ( https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023 ). Do you have an opinion about it? Do I understand correctly that the issue is that OutputToSource values can be absolute or relative paths? That would be fixable by patching only UpdateOutputToSourceMap, right? Not exactly. According to my tests only cmMakefiles::GetSourceFileWithOutput's cname argument can be either relative or absolute. Then patching the callers of GetSourceFileWithOutput is worth looking into. There are not many. You'd have to try it and see if any issues come up. Ok. I will give it a try tomorrow. I hope it won't bring in part of CMake I do not know. Hi Stephen, I think I need your insight of CMake code base here. According to my tests (ie ExportImport and CustomCommand), GetSourceFileWithOutput() is called with a relative path only from here: https://github.com/Kitware/CMake/blob/master/Source/cmTarget.cxx#L1939 How can I convert this name to an absolute path? Cheers, -- Nicolas Desprès -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote: Hi Stephen, I think I need your insight of CMake code base here. According to my tests (ie ExportImport and CustomCommand), GetSourceFileWithOutput() is called with a relative path only from here: https://github.com/Kitware/CMake/blob/master/Source/cmTarget.cxx#L1939 How can I convert this name to an absolute path? Find out which of the callers of FollowName() call it with a relative path. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_link_libraries, IMPORTED targets and SYSTEM includes
On 07/25/2013 01:25 PM, Stephen Kelly wrote: Either way, the tll() SYSTEM option could still be useful. I'll add that tomorrow. Can we wait until after 2.8.12 to add this? We're already adding the new tll signature and policy CMP0023. I'd like to avoid confusion of new and old signatures w.r.t. availability of the SYSTEM option. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_link_libraries, IMPORTED targets and SYSTEM includes
Brad King wrote: On 07/25/2013 01:25 PM, Stephen Kelly wrote: Either way, the tll() SYSTEM option could still be useful. I'll add that tomorrow. Can we wait until after 2.8.12 to add this? We're already adding the new tll signature and policy CMP0023. I'd like to avoid confusion of new and old signatures w.r.t. availability of the SYSTEM option. Yes, after the follow up emails and the possible change in scope with a target property etc, I had the same idea. I don't want to add anything new to delay 2.8.12. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] link-language-static-lib topic
Steve,
In these hunks:
- if(this-GetType() == cmTarget::STATIC_LIBRARY)
+ if(this-LinkLanguageDependsOnLinkImplementation())
...
+ bool LinkLanguageDependsOnLinkImplementation() const
+ { return this-TargetTypeValue == STATIC_LIBRARY; }
The description of the test as link language depends
on link implementation is not correct. The blocks
guarded by this test are about setting the interface
link languages of a static library to propagate to
dependents, not the link language of the target itself.
Perhaps
bool LinkLanguagePropagatesToDependents() const
{ return this-TargetTypeValue == STATIC_LIBRARY; }
or
bool LinkLanguageInInterface() const
{ return this-TargetTypeValue == STATIC_LIBRARY; }
is better? Other ideas for a better name?
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] link-language-static-lib topic
Brad King wrote:
Perhaps
bool LinkLanguagePropagatesToDependents() const
{ return this-TargetTypeValue == STATIC_LIBRARY; }
I think this one is fine. I've re-pushed the commit to the minor-cleanups
topic.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies
On Wed, Jul 24, 2013 at 10:48 AM, Nicolas Desprès nicolas.desp...@gmail.com wrote: On Tue, Jul 23, 2013 at 5:59 PM, Stephen Kelly steve...@gmail.com wrote: Nicolas Desprès wrote: Hi Stephen, Did you have any chance to look at the code? I would love to see it integrated in the next release. That being said, there is no pressure. I'll have a look now. Thanks! +UpdateOutputToSourceMap(outputs, file); is missing a 'this-', as per the style. There's a couple of repeats of that. Done Please rename typedef std::mapstd::string, cmSourceFile* OutputToInputMap; to OutputToSourceMap for similarity to the OutputToSource variable. Done I haven't tried it out yet, but it looks sane to me. The UpdateOutputToSourceMap could probably be faster if outputs is sorted and you use lower-bound insertion in a loop over the map or so. If it's fast enough already though, probably no need for that :). Currently, it is fast enough. The path to optimize was search not the insertion. I have not noticed any performance regression in the insertion. I liked your idea of inserting in at the end of list/vector and then to sort it once the configuration is done but I am afraid this require more knowledge of cmake code base than I have and the patch will be harder to write. That's said we can optimize further as I mentioned in my comment ( https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023). Do you have an opinion about it? That was not true! It was fastest because it was not doing the right thing. I tried to patch it properly and the benchmark are the same whether we use the default comparison functor or mine. So I think you can merge it like that. I have pushed a new version without the comment. Thaks, -- Nicolas Desprès -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake -E tar not working correctly with xz-compressed tarballs on MSYS
On 2013-07-25 16:16-0700 Alan W. Irwin wrote: On 2013-07-25 15:31-0400 Brad King wrote: On 07/24/2013 03:27 PM, Alan W. Irwin wrote: The first priority is to verify on Microsoft Windows that this is actually an issue using the the simple test I outlined in my previous post. At a MSYS prompt under MS Windows this works: $ cat a.tar.xz | unxz | tar x but this hangs: $ cmake -E tar xvf a.tar.xz One can see in the process tree that there is a child process of cmake called unxz that was started with no command line arguments. One can attach a debugger to see CMake blocked inside libarchive code. This confirms that the hang occurs on MS Windows just as in Wine. I suggest getting upstream libarchive and building its sample tools but without lzma support built-in. Then try using that binary to extract the .tar.xz file. Thanks, Brad, for that Microsoft Windows confirmation, and I will follow your advice for the rest to try and track down whether the problem is for the libarchive upstream version or the libarchive version within CMake. With luck I should be able to come up with a fix as well (since drop-through to command-line handling of *.tar.xz should be completely straightforward) assuming the MSYS version of gdb works similarly to the Linux version (which I am familiar with). Hi Brad: Here is progress so far. I used git to obtain the latest git version of libarchive (v3.1.2-40-g4b5f651). I built and tested the result on Linux using cmake ... -DENABLE_TEST:BOOL=ON ... make VERBOSE=1 -j4 all.out make VERBOSE=1 -j4 test test.out make VERBOSE=1 -j4 install install.out In some cases (e.g., lzma) I did not have the required development version of the linux libraries installed so it (presumably) used the fallback command-line tools instead. All was well including 100 per cent passage of the tests so this seems to be a pretty good version of libarchive. For MinGW-4.7.2/MSYS/Wine-1.6-rc4 I went through exactly the same build and test procedure for MSYS Makefiles. In virtually all cases (including lzma) it could not find the libraries so it (presumably) used the fallback command-line tools instead. The all and install targets ran without issues, but 36 tests failed out of 400. I don't know how many of those are due to general issues for libarchive on the MSYS platform and how many are due to Wine-1.6-rc4, but the track record of Wine so far for my build and test experients is most/all of those will be due to MSYS. I have attached a compressed tarball containing the *.out files in case you would like to compare with your own MSYS build. From the perspective of the current issue, the important result from the above tests is that the lzma tests did pass and also all extraction tests. I also tried two simple tests of the installed bsdtar executable: bash.exe-3.1$ ../install/bin/bsdtar.exe xJf \ /z/home/wine/newstart/test_tar_h/test_xz/test.tar.xz bash.exe-3.1$ ../install/bin/bsdtar.exe tJvf \ /z/home/wine/newstart/test_tar_h/test_xz/test.tar.xz Those tests had no issues. So it appears to me that for extraction at least and also in particular for *.tar.xz extraction, the upstream git version (v3.1.2-40-g4b5f651) of libarchive is fine on MSYS (and also Linux). So would you be willing to import v3.1.2-40-g4b5f651 into CMake to see if that solves the cmake -E tar issue that I found with xz-compressed tarballs? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ libarchive_build_test_results.tar.gz Description: compressed tarball containing *.out files from MSYS build and test of libarchive -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
Hi,
I pushed the IntroduceTARGETSVariable branch to stage.
It introduces the new variable Foo_TARGETS to be used in Config files,
additionally to or maybe better instead of Foo_LIBRARIES and Foo_INCLUDE_DIRS.
This variable shall be used to list the target(s) imported by the package Foo.
So it can be used in tll() calls to link against the library (package).
What makes it differ from Foo_LIBRARIES, is that CMake checks that each of the
items listed in this variable
* is an existing target
* has the INTERFACE_INCLUDE_DIRS property set.
This should make sure that using this variable in a tll() call should suffice
to give the target the required include dirs and libraries.
IMO this has multiple advantages:
* using
tll(hello ${Foo_TARGETS} )
instead of
tll(hello foo )
gives the reader a strong hint that ${Foo_TARGETS} comes from a
find_package(Foo) call, while in the second case it is not clear at
all whether foo is an in-project target, an imported target or
the basename of a library.
This doesn't matter much for the developer who added the dependency
to foo himself, since he knows what he's doing at this moment, but it
matters a lot for everybody else, who have to find out what's going on, be
it a developer new to this code or somebody trying to debug build problems
of somebody else's project via a mailing list.
* using
tll(hello ${Foo_TARGETS} )
instead of
tll(hello ${Foo_LIBRARIES} )
tells the reader that by using ${Foo_TARGETS} there is need for
an additional call to set the include dirs, but that the include dirs are
coming attached to the targets listed in ${Foo_TARGETS}.
This is actually enforced with this patch.
Again, this helps a lot when reading cmake code you didn't write yourself.
* there is a direct mapping from the package name Foo used in
find_package(Foo) to the variable name Foo_TARGETS. This is something
I heard many people wishing for/complaining about.
This cannot be enforced when using target names directly (this would mean
that the name of the Config.cmake file must be exactly the name of the
target to use, and there is no enforcement of namespaces like Foo::
possible).
* with this variable, for many projects Foo_TARGETS will be the only variable
which needs to be set in the Config.cmake file, so they become simpler.
It has one disadvantage, which is that with this new variable there are now
two standards: either use ${Foo_LIBRARIES} and ${Foo_INCLUDE_DIRS}, or use
${Foo_TARGETS}.
Error messages
--
In the case that a target does not exist, the following error message is
generated:
CMake Warning at /opt/ecm/share/ECM/find-modules/FindKF5.cmake:180
(find_package):
Found package configuration file:
/opt/kf5/lib/cmake/KCoreAddons/KCoreAddonsConfig.cmake
but KCoreAddons is considered to be NOT FOUND because the variable
KCoreAddons_TARGETS set by it lists the following non-existant targets: Foo
Call Stack (most recent call first):
CMakeLists.txt:14 (find_package)
In the case that a target is listed. which does not have the include dirs set,
the following error message is generated:
CMake Warning at /opt/ecm/share/ECM/find-modules/FindKF5.cmake:180
(find_package):
Found package configuration file:
/opt/kf5/lib/cmake/KCoreAddons/KCoreAddonsConfig.cmake
but KCoreAddons is considered to be NOT FOUND because the variable
KCoreAddons_TARGETS set by it lists the following targets which do not have
the required INTERFACE_INCLUDE_DIRECTORIES target property set:
KF5::KCoreAddons
Call Stack (most recent call first):
CMakeLists.txt:14 (find_package)
TODO
* Tests are still missing.
* Should the variable be mentioned in the documentation for find_package() ?
* There is the theoretical risk that there are Config.cmake files out there
which set a variable with that name already, but without the include dir
property. Should this be based on a policy, so that the error is only
generated if cmake 2.8.12 or higher is required ? Or should there be an
emergency switch -DCMAKE_IGNORE_MISSING_INCLUDE_DIRS_ON_IMPORTED_TARGETS for
this case ?
Comments ?
If possible, I'd like to get that into 2.8.12.
Thanks
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake -E tar not working correctly with xz-compressed tarballs on MSYS
On 07/26/2013 01:57 PM, Alan W. Irwin wrote: So would you be willing to import v3.1.2-40-g4b5f651 into CMake to see if that solves the cmake -E tar issue that I found with xz-compressed tarballs? We've been due for a libarchive update anyway. I just updated it locally to release version 3.1.2 and it does fix the problem! I'll finish the full update and integration into CMake when I get a chance. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake -E tar not working correctly with xz-compressed tarballs on MSYS
On 2013-07-26 17:03-0400 Brad King wrote: On 07/26/2013 01:57 PM, Alan W. Irwin wrote: So would you be willing to import v3.1.2-40-g4b5f651 into CMake to see if that solves the cmake -E tar issue that I found with xz-compressed tarballs? We've been due for a libarchive update anyway. I just updated it locally to release version 3.1.2 and it does fix the problem! I'll finish the full update and integration into CMake when I get a chance. Thanks! Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014318]: ExternalProject module needs small patch to allow unpacking of *.tar.xz files
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14318 == Reported By:irwin Assigned To: == Project:CMake Issue ID: 14318 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2013-07-26 19:44 EDT Last Modified: 2013-07-26 19:44 EDT == Summary:ExternalProject module needs small patch to allow unpacking of *.tar.xz files Description: The CMake logic in ExternalProject.cmake does tests for filename patterns which currently do not contain the pattern for *.tar.xz. The attached patch fixes this issue so that ExternalProject_Add correctly unpacks *.tar.xz files on Linux. Steps to Reproduce: Use ExternalProject_Add to attempt to unpack a *.tar.xz tarball on Linux. Additional Information: Note there is a related fix (consisting of importing the latest libarchive source code into CMake) in the works that should allow cmake -E tar xfz *.tar.xz to work properly on MSYS. When that fix is combined with the present one the result will be that ExternalProject_Add correctly unpacks *.tar.xz files on MSYS (as well as Linux). == Issue History Date ModifiedUsername FieldChange == 2013-07-26 19:44 irwin New Issue 2013-07-26 19:44 irwin File Added: ExternalProject.cmake.patch == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake -E tar not working correctly with xz-compressed tarballs on MSYS
On 2013-07-26 17:03-0400 Brad King wrote: I'll finish the full update and integration into CMake when I get a chance. When you do that please make sure the small file-pattern patch to ExternalProject.cmake given at http://public.kitware.com/Bug/view.php?id=14318 gets into CMake so that that your fix to allow unpacking of *.tar.xz tarballs on MSYS can be used via ExternalProject_Add. The file-pattern patch also allows unpacking of *.tar.xz tarballs on Unix via ExternalProject_Add. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
