Re: [cmake-developers] Unexpected bad status for file DOWNLOAD for http://*.xz URLs
2013/7/12 Alan W. Irwin ir...@beluga.phys.uvic.ca:
On 2013-07-11 16:30-0700 Alan W. Irwin wrote:
These commands
file(DOWNLOAD
http://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz;
/home/software/plplot_svn/HEAD/plplot_allura/cmake/build_projects/cmake_downloaded_glib-2.32.1.tar.xz
SHOW_PROGRESS STATUS status)
message(STATUS Download status = ${status})
instantly give me the following results:
-- [download 0% complete]
-- Download status = 1;unsupported protocol
[...]
Then may be the unsupported protocol is not http...keep reading
So I hope someone else will also try experiments to see if they can
discover _any_ http://*.tar.xz URL that can be downloaded by
file(DOWNLOAD...).
If I use the curl -L options you use I can see:
GET /sources/glib/2.32/glib-2.32.1.tar.xz HTTP/1.1
Location: https://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz
Issue another request to this URL:
'https://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz
GET /sources/glib/2.32/glib-2.32.1.tar.xz
Location: http://ftp.gnome.org/pub/GNOME/sources/glib/2.32/glib-2.32.1.tar.xz
Issue another request to this URL:
'http://ftp.gnome.org/pub/GNOME/sources/glib/2.32/glib-2.32.1.tar.xz
GET /pub/GNOME/sources/glib/2.32/glib-2.32.1.tar.xz
...
then it seems that the initial http URL is redirected to https which
is redirected to ftp...
then I tried my CMake build with with your:
file(DOWNLOAD
http://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz;
/tmp/cmake_downloaded_glib-2.32.1.tar.xz
SHOW_PROGRESS STATUS status)
message(STATUS Download status = ${status})
and it works as expected.
so my best bet is that the CMake command your are using has no SSL support
which makes the https handling fail with unsupported protocol.
--
Erk
L'élection n'est pas la démocratie -- http://www.le-message.org
--
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] Unexpected bad status for file DOWNLOAD for http://*.xz URLs
On 2013-07-12 11:21+0200 Eric Noulard wrote: so my best bet is that the CMake command your are using has no SSL support which makes the https handling fail with unsupported protocol. Hi Eric: Your hypothesis was absolutely correct (as you can see from my later posts in this thread). In fact, the Debian wheezy version of cmake cannot handle my test case, and the only version I got to work was my own build with a particular choice of system curl library. What was the exact version of CMake that you found would pass my download test? By bringing the openssl library build in house (similar to the way there is an in-house version of libcurl), I think CMake could be made a lot less fragile with respect to downloading. 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 0014288]: eCos platform enforces GNU compiler
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14288
==
Reported By:Emmanuel Blot
Assigned To:
==
Project:CMake
Issue ID: 14288
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-07-12 12:30 CEST
Last Modified: 2013-07-12 12:30 CEST
==
Summary:eCos platform enforces GNU compiler
Description:
I am building eCos kernel and eCos-based project with Clang (3.3), but
share/cmake/Modules/Platform/eCos.cmake enforces a GNU compiler, whereas it
should tolerate a Clang compiler:
CMAKE_FORCE_C_COMPILER (${xcc} Clang)
CMAKE_FORCE_CXX_COMPILER (${xcc} Clang)
should be used, but
CMAKE_FORCE_C_COMPILER (${xcc} GNU)
CMAKE_FORCE_CXX_COMPILER (${xcc} GNU)
is mandatory due to these lines in share/cmake/Modules/Platform/eCos.cmake
if(CMAKE_C_COMPILER AND NOT ${CMAKE_C_COMPILER_ID} MATCHES GNU AND NOT
_IN_TC)
message(FATAL_ERROR GNU gcc is required for eCos)
endif()
if(CMAKE_CXX_COMPILER AND NOT ${CMAKE_CXX_COMPILER_ID} MATCHES GNU AND NOT
_IN_TC)
message(FATAL_ERROR GNU g++ is required for eCos)
endif()
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-12 12:30 Emmanuel Blot New Issue
==
--
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] Working towards Windows Phone 8 support
Hi CMake developers! I'm interested in contributing towards Windows Phone 8 support in CMAKE, i.e. http://public.kitware.com/Bug/view.php?id=13791 I'm working on a patch that will allow C/C++ static libraries (.lib) to be built with CMAKE. The patch creates a Visual Studio 2012 (v11) .vcxproj file per library using a new Visual Studio 11 Windows Phone 8 generator. This .vcxproj: 1. Targets the Windows Phone 8 platform toolset (v110_wp80). 2. Has content that allows MSBUILD/Visual Studio to build a .lib target for either Win32 (x86 emulator) and ARM (devices) platforms. How should I go about getting my work reviewed at an early stage? (I am a first-time CMAKE contributor: I have set up no dev or Mantis accounts yet, and have only just recently joined this mailing list). Many thanks, Paul Annetts. -- 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_SYSROOT vs CMAKE_OSX_SYSROOT
Brad King wrote: On 07/11/2013 11:08 AM, Brad King wrote: Can anyone else think of complications? Side note: If we cannot resolve this soon we should revert CMAKE_SYSROOT before 2.8.12 to leave room for the two to be combined later. I've reverted it now. I've also removed the replace-CMAKE_SYSROOT_FLAG branch from next, and squashed it into the re-commit of the initial feature and pushed the result to my clone as add-CMAKE_SYSROOT. 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] Deprecating qt4_use_modules and qt4_automoc?
clin...@elemtech.com wrote: What is the motivation for deprecating these? Can we just let them fade away on their own as the world moves from Qt4 to Qt5? This is entirely orthogonal to Qt 5. qt4_use_modules is new, but provides no benefit over tll(). We shouldn't encourage adoption of it for people who are already depending on 2.8.11. qt4_automoc is suboptimal, not present in the Qt 5 macros, and made obsolete by the CMAKE_AUTOMOC feature. With two similar features, one of them should be marked obsolete. 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] Why does this work - linking against a library before it has been defined ?
Alexander Neundorf wrote: Hi, I was surprised today, something worked which I expected to fail: Can you say which version of cmake this did fail with? Note that it is more likely to *compile* since 2.8.11 because includes and defines are part of the target interface, but linking should be unchanged. 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] Any idea why some dashboards fail with Qt4?
This result is surprising: http://open.cdash.org/testSummary.php?project=1name=RunCMake.ObsoleteQtMacrosdate=2013-07-12 There is a QT4_WORKS test in Tests/CMakeLists.txt. Is that hiding this issue in other Qt4 based unit tests? Rather than hiding the issue, and idea what's going on? 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] CMake is slow for project with hundred target and one command with large number of dependencies
Hi all,
I am using CMake again since a couple of weeks for a project involving the
build of recognition system. This system is made of hundred sub recognition
system that must be all trained with about ~10k files as input.
I ended up writing something like that:
== BEGIN
# A project with hundred targets depending on one command with 10k
dependencies.
cmake_minimum_required(VERSION 2.8)
project(HundredTargetsDepOnOneCommandWithManyDeps)
include(CTest)
# Define LARGE_LIST with 1 input files.
include(large_list.cmake)
foreach(i ${LARGE_LIST})
file(WRITE ${i} input)
endforeach(i)
add_custom_command(
OUTPUT bottle_neck
COMMAND ${CMAKE_COMMAND} -E touch bottle_neck
DEPENDS ${LARGE_LIST}
COMMENT Executing command with large number of dependencies...
)
set(OUTPUTS )
foreach(i RANGE 100)
set(_output output_${i})
add_custom_target(${_output}-target ALL
DEPENDS bottle_neck
)
list(APPEND OUTPUTS ${_output})
endforeach(i)
add_executable(AlwaysTrue AlwaysTrue.c)
== END
Note that the hundred targets have only one dependency. Running CMake on
this project is slow. The configuration is fast but the generation is very
slow. Here some examples:
With Unix Makefiles
$ time make rebuild_cache
Running CMake to regenerate build system...
-- Configuration done
(this is long)
-- Generation done
(this is long)
-- Build files have been written to: ...
make rebuild_cache 120.54s user 6.08s system 97% cpu 2:10.07 total
Memory used is normal (htop indicates 82488 VIRT) and CPU is at 100%.
$ time make
make 129.46s user 3.76s system 99% cpu 2:14.28 total
With Ninja:
$ time ninja -v rebuild_cache
ninja rebuild_cache 98.89s user 0.10s system 99% cpu 1:39.02 total
$ time ninja
ninja 0.01s user 0.04s system 86% cpu 0.055 total
So here my two questions:
1/ Do you think it is possible to improve the performance? (I have not
profile it yet).
2/ Is there a way to set a timeout to ctest so that my test fail. I have
that in Tests/CMakeLists.txt but it does not work:
set(_test_name HundredTargetsDepOnOneCommandWithManyDeps)
add_test(${_test_name} ${CMAKE_CTEST_COMMAND}
--build-and-test
${CMake_SOURCE_DIR}/Tests/${_test_name}
${CMake_BINARY_DIR}/Tests/${_test_name}
--build-two-config
${build_generator_args}
--build-project ${_test_name}
--timeout 10
--test-command AlwaysTrue)
list(APPEND TEST_BUILD_DIRS
${CMake_BINARY_DIR}/Tests/${_test_name})
unset(_test_name)
I have pushed my work so far on my github clone of CMake.
https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf
I am willing to do the work on this topic but I wanted to have your insight
first.
Thanks,
--
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] Roadmap to 2.8.12
On Friday 12 July 2013, Stephen Kelly wrote: Stephen Kelly wrote: Yes, apart from tll-new-signatures, I'd like to try to get the export-policy and target-LOCATION-policy topics from my clone into 2.8.12. Actually, the export-policy branch deprecates the ability to write code like export(TARGETS foo FILE fooTargets.cmake) include(fooTargets.cmake) without providing a more modern alternative (ALIAS targets). I think that policy should be in the release which introduces ALIAS targets, so I don't recommend getting export-policy or target-LOCATION-policy into 2.8.12. I've pushed an implementation of ALIAS-targets to my clone. It's actually very simple, so I'm confident we can get it into the next release. What was the purpose of those ALIAS targets, was it for header-only libraries ? 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 is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote:
I have pushed my work so far on my github clone of CMake.
https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf
Something must have gone wrong with the push :)
stephen@hal:~/dev/src/cmake{master}$ git show origin/master | grep commit
commit b9412889e9c5028e32ef3b978d8cdd1175f14b0f
stephen@hal:~/dev/src/cmake{master}$ git show nicolasdespres/topic/large-
deps-perf | grep commit
commit b9412889e9c5028e32ef3b978d8cdd1175f14b0f
I noticed a lot of obsolete branches in your clone. I noticed a lot of
branches, but mostly it looks like ninja stuff that's already been merged.
Is there anything else interesting there?
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] Unexpected bad status for file DOWNLOAD for http://*.xz URLs
On 2013-07-12 23:33+0200 Eric Noulard wrote: Seriously, though, what do you do in the Windows case where there is no trusted distribution to build the openssl library for you? I presume you download some Windows binary from a location you trust, but what location is that? Then ask your windows provider to provide one. Actually, I don't have a windows provider since my Windows platform is Wine where it is the user's responsibility to download or build any additional libraries beyond the fundamental Windows ones that the user might need. So since the KitWare developers have to make a decision about this security issue for their own distribution of the CMake binary version for Windows, I was asking them for a recommendation for a trusted version of ssh for Windows platforms that I could use myself on Wine. I don't really understand your response to my question. Who better to ask than your open-source friends for a recommendation of a trustworthy supplier of the Windows binary version of the openssl library? 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
Re: [cmake-developers] Unexpected bad status for file DOWNLOAD for http://*.xz URLs
On Jul 12, 2013, at 4:27 PM, David Cole wrote: It’s a bad bad really bad idea to make the build of OpenSSL “in-house” as you’ve been calling it... CMake SHOULD use the system openssl for distributions that have one already. I must have missed where ignoring a system version was implied. The question seems to be squarely on ones that do not have it, no? I've asked providers and even advocate using alternates, but at the end of the day one still needs to compile on a myriad of environments that don't have [insert dependency here]. If there are problems with that approach, then the problems should be addressed, but bringing a security component into “we have our own custom build of that which you must use”-land is NEVER a good idea. Saying that which you must use is fallacious. It can be set up to be optionally utilized only when there is not one available. In much commercial industry, at least for most proprietary software I've ever worked with, it's a fundamental tenant of configuration control. For platforms that specify self-contained binaries or stand-alone installers, it's pretty much requisite. Just my opinion. Feel free to flame me if I’m wrong. It's a common opinion to be had after using nice package management systems and even I've been guilty of it, but I think a substantial portion of industry is not able to rely on that. Look at nearly any piece of proprietary UNIX software you can buy in a box and you'll usually find it's exceptionally self-contained (if they're at all portable). If they're not a target audience, so be it. I agree with your assessment that the build should produce a warning/error somewhere if CMake is built without openssl support, but I think you’ll find that a tough sell to some other important CMake devs. Bundled is the most convenient since it can be made to always -just work- if it's not detected. A error with a URL is the polite way to say action is required without bundling. Cheers! Sean -- 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
