[cmake-developers] Namespaces
Hello, I am adding several third-party projects as static libraries in my project. This is what I do: CMakeLists.txt | \-- 3rdparty | \ pugixml | \ QtZeroConf | \ QtDropBox | \ websocketpp In the root CMakeLists.txt, I have: add_subdirectory(3rdparty) And in 3rdparty/CMakeLists.txt: add_subdirectory(pugixml/scripts) add_subdirectory(QtZeroConf) add_subdirectory(QtDropBox) add_subdirectory(websocketpp) This is an easy way to work with third-party dependences. My problem comes from the fact several of these third-party libraries use common variable names, e. g. BUILD_SHARED, BUILD_TESTS, etc). Has some kind of namespacing been considered for add_subdirectory? E. g. add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) Which would lead to all the variables defined QtZeroConf/CMakeLists.txt having a QTZEROCONF_ prefix, e. g. instead of BUILD_SHARED it would now be QTZEROCONF_BUILD_SHARED. Or, as an alternative: add_subdirectory QtZeroConf NAMESPACE QtZeroConf) and variables would be prefixed by QtZeroConf::, e. g. BUILD_SHARED would now be QtZeroConf::BUILD_SHARED. Does that sound sensible? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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] Namespaces
On Thu, Jan 28, 2016 at 7:17 PM, Stephen Kelly <steve...@gmail.com> wrote:
> > Has some kind of namespacing been considered for add_subdirectory?
> >
> > E. g.
> >
> > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF)
>
> And what if someone builds your project with -DBUILD_SHARED=ON? Are you
> going to use
>
> set(QTZEROCONF_BUILD_SHARED ${BUILD_SHARED})
> add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF)
>
> for every variable you're wrapping? Or do you want cmake to do that for
> every variable in scope when the directory is added? How would cmake decide
> which variables to namespace?
>
>
CMake should wrap every variable defined under the directory added with
add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF), no need for me to
manually wrap anything.
> You should use ExternalProject instead, or fork the buildsystem of those
> projects to integrate them into your project. Not that I recommend the
> latter for you though :). That's what cmake does when integrating 3rd party
> code.
>
>
Unfortunately ExternalProject does not work well with find_package, e. g.
this fill fail:
CMakeLists.txt
|
\--- 3rdparty/CMakeLists.txt
\--- server/CMakeLists.txt
Where:
3rdparty/CMakeLists.txt contains ExternalProject_Add(QtZeroConf ...)
and
server/CMakeLists.txt contains find_package(QtZeroConf)
This can be alleviated by using Hunter ( https://github.com/ruslo/hunter ),
by modifying the third-party CMakeLists.txt ( https://coderwall.com/p/y3zzbq
) or by manually setting the imported library location (
http://mirkokiefer.com/blog/2013/03/cmake-by-example/) but it's cumbersome.
My solution is much, much easier and requires no modification at all to the
third-party.
In fact, I think in addition to add_subdirectory( ... NAMESPACE ... ),
there should be something like find_package( QtZeroConf EXTERNAL_PROJECT
QtZeroConf), indicating the package is built by means of ExternalProject
and therefore, finding the package should be delayed until after that
external project has been built. That would make the tricks above
unnecessary.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
--
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] Namespaces
On Thu, Jan 28, 2016 at 9:58 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
wrote:
> Your experience is contrary to mine. For example, in my epa_build
> project (where I build all the many prerequisites of PLplot) I build a lot
> of
> different libraries (such as Qt5 and the GTK+ stack of libraries) using
> ExternalProject_Add, and I don't experience any difficulties using
> find_package to find the installed results.
>
> I assume find_package should work well with ExternalProject_Add for
> you as well so long as (a) all your ExternalProject(s) are configured
> to do both a build and install (not just a build), and (b) you are
> being careful in server/CMakeLists.txt to set PATH,
> CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH, and PKG_CONFIG_PATH
> consistently with the install prefix used for the ExternalProject(s).
>
>
It works well for you because you actually have two things there:
- PlPlot
- A superbuild that builds the dependencies required to build PlPlot,
and then, PlPlot itself by way of ExternalProject_Add (using
download_command = copy the source code from some directory to another)
But what I would like to do with ExternalProject_Add (and please note this
is a different topic than what I started the thread for) is to avoid that
superbuild:
CMakeLists.txt
|
\--- 3rdparty
|
\--- server
|
\--- client
|
\--- app
Where the root CMakeLists.txt is something like this:
--8<---
project(myapp)
# ExternalProject used here to build dependencies
add_subdirectory(3rdparty)
# My software is built directly, not through a superbuild
add_subdirectory(server)
add_subdirectory(client)
add_subdirectory(app)
--8<---
and 3rdparty/CMakeLists.txt would be something like this:
--8<---
include(ExternalProject)
# websocketpp
ExternalProject_Add(websocketpp
SOURCE_DIR ${CMAKE_BINARY_DIR}/websocketpp
DOWNLOAD_DIR ${MYAPP_DOWNLOADS_DIR}
INSTALL_DIR ${MYAPP_INSTALL_DIR}
URL ${websocketpp_URL}
URL_MD5 ${websocketpp_MD5}
CONFIGURE_COMMAND ${CMAKE_COMMAND}
-DCMAKE_INSTALL_PREFIX=${MYAPP_INSTALL_DIR} ${CMAKE_BINARY_DIR}/websocketpp
LOG_DOWNLOAD 1
LOG_UPDATE 1
LOG_CONFIGURE 1
LOG_BUILD 1
LOG_TEST 1
LOG_INSTALL 1
)
# QtZeroConf
ExternalProject_Add(QtZeroConf
SOURCE_DIR ${CMAKE_BINARY_DIR}/QtZeroConf
DOWNLOAD_DIR ${MYAPP_DOWNLOADS_DIR}
INSTALL_DIR ${MYAPP_INSTALL_DIR}
GIT_REPOSITORY ${QtZeroConf_URL}
CONFIGURE_COMMAND ${QT_QMAKE_EXECUTABLE} PREFIX=${MYAPP_INSTALL_DIR}
${CMAKE_BINARY_DIR}/QtZeroConf
LOG_DOWNLOAD 1
LOG_UPDATE 1
LOG_CONFIGURE 1
LOG_BUILD 1
LOG_TEST 1
LOG_INSTALL 1
)
--8<---
Now I should be able to do:
server/CMakeLists.txt
--8<---
project(server)
find_package(websocketpp REQUIRED)
find_package(Boost REQUIRED COMPONENTS date_time system thread)
set(server_SOURCES main.cpp server.cpp)
add_executable(server ${server_SOURCES})
target_link_libraries(server ${WEBSOCKETPP_LIBRARY} ${Boost_LIBRARIES})
--8<---
That would feel natural, wouldn't it?
But that does not work unless I juggle with add_library(... IMPORTED) or I
use Hunter or alike.
In the end, neither the current behavior of add_subdirectory nor the
current behavior of ExternalProject_Add let me work in the seemingly most
natural way: tell CMake to build my dependencies, then immediately work on
my applications/libraries :-(
I would love to work on this, as Stephen suggested, but I just don't have
the time :-/
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
--
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] Namespaces
On Thu, Jan 28, 2016 at 8:21 PM, Stephen Kelly <steve...@gmail.com> wrote: Pau Garcia i Quiles wrote: > > > CMake should wrap every variable defined under the directory added with > > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) > > So, CMake needs to first determine what variables are used in the > QtZeroConf > directory (presumably without executing the cmake code there) and then wrap > the variables, then execute the cmake code? > I must be missing something. I don't think that's possible. > > I think it's just a matter of adding an "internal note" saying "OK, I'm going to namespace variables from now on" in cmAddSubdirectoryCommand when add_subdirectory contains NAMESPACE, and then modifying the literal of the variable in cmSetCommand.cxx (first argument to AddDefinition here in line 165): this->Makefile->AddDefinition(variable, value.c_str()); https://github.com/Kitware/CMake/blob/master/Source/cmSetCommand.cxx#L165 > 3rdparty/CMakeLists.txt contains ExternalProject_Add(QtZeroConf ...) > > > > and > > > > server/CMakeLists.txt contains find_package(QtZeroConf) > > I think you need: > > ExternalProject_Add(3rdparty/Whatever ...) > ExternalProject_Add(3rdparty/QtZeroConf ...) > ExternalProject_Add(server ...) > > and pass appropriate args to the latter, including where to look for > dependencies etc (and dependencies among the ExternalProjects). > > You might not like this solution, but as far as I know it is the only > correct solution built into CMake. > > The only thing I like about that solution is it's doable today with CMake. But I think my approach would prove much easier and direct for developers using CMake: add_subdirectory(dir NAMESPACE blah) and find_package(whatever EXTERNAL_PROJECT epwhatever). -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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] Namespaces
On Thu, Jan 28, 2016 at 9:19 PM, Ben Boeckel <ben.boec...@kitware.com> wrote: > I think the solution to your problem is to use INTERNAL cache variables > (for cache variables created by the third party project) or local > variables to override the cache variables in scope (which would likely > work for BUILD_SHARED_LIBS or ENABLE_TESTING). > > Unfortunately, using INTERNAL cache variables requires me to modify the third-party library, which is exactly what I do not want to do. I want to be able to drop the third-party in a folder, add_subdirectory and form then on, use it. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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] CMake alternative language (was: Using CMake as a library from Python)
On Fri, Jan 8, 2016 at 5:30 PM, Brad King <brad.k...@kitware.com> wrote: > See above. Lua has come up several times in the past in particular because > its implementation is meant to be small and embeddable. I've thought a few > times about how to make Lua scripting available from within the CMake > language > in a clean way, but that will not be as valuable as the above pure-spec > approach. > > Please, do not do that. The moment you make CMake scriptable in more than one language, you are forcing every CMake user to learn that additional language because sooner or later he will step into a third-party that is using that additional language. IMHO, if you want Lua, then Lua it is. But then please get rid of CMake scripting. BTW, I am sure you are aware of CMakeScript, CMake scripting in JavaScript: http://sourceforge.net/projects/cmakescript/ Also, declarative? Why? There are already a few declarative build systems (e. g. qbs, one of the reasons for its existence was CMake was not declarative). By moving CMake from the current procedural scripting to a declarative approach, you may alienate your current user base and be good for none anymore. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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] ExternalProject EXTRACT_COMMAND (was: New feature, git access)
On Tue, Nov 26, 2013 at 4:26 PM, Brad King brad.k...@kitware.com wrote:
The test fails for me with spaces in the path because you're writing
the extraction command into the script without quoting so the spaces
cause incorrect parsing at build time. You can write it as
file(WRITE ...
...
set(extract_command ${extract_command})
...
... COMMAND \${extract_command} ...
...
)
so that the exact value of the command is stored in the script and
expanded when evaluated at build time. It is probably simplest to
refactor the default extraction command to be written into the script
in this way also. Then you simply don't generate the default when an
explicit command is passed.
If I understand correctly what you mean, that would require either:
- Duplicating the test for extensions in both the extract-target.cmake
and the current location so that we can fail in CMake generation time if a
file we don't know how to extract is passed
or
- Failing (error: do not know how to extract...) only in compilation time
Or maybe I'm missing something?
The EXTRACT_COMMAND needs a way to have a placeholder for the file name
so that the caller does not need to know where ExternalProject keeps
the file after downloading.
Actually, the test was wrong: the filename is automatically appended to the
end. I. e. EXTRACT_COMMAND is exactly that: the command, not the command +
filename:
EXTRACT_COMMAND ${CMAKE_COMMAND} -E tar xvf
not
EXTRACT_COMMAND ${CMAKE_COMMAND} -E tar xvf /path/to/file
However, the placeholder could prove useful if the filename needs to go in
the middle of the EXTRACT_COMMAND. Do you have any suggestion of should I
make something up, like, say, # ?
I am attaching a new patch, which fixes the path-with-spaces issue. No
placeholder has been implemented yet.
I don't understand the ...After you have been invited...
in http://www.cmake.org/Wiki/CMake/Git/Account#Git
(who would know I need an invitation!?)
The sentence immediately preceding that says See our new maintainer
instructions to join and has a link to the instructions. They have
a step for posting to this list for discussion. We invite productive
contributors for direct access in due time.
My bad :-) I visited the link, read the instructions but on step 4 I was
only reading until Subscribe to the CMake Developers Mailing List. As I
was already subscribed, I didn't look any further O:-)
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
epa-extract-command-20131127-1031.patch
Description: Binary data
--
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] New feature, git access
Hello, I have implemented an EXTRACT_COMMAND for ExternalProject_Add. It is useful in case you are downloading a file that CMake does not know how to extract, but you do (e. g. NSIS installers that can be extracted without installation, self-extracting ZIP files, etc). Code is here for now: https://elpauer.assembla.com/code/elpauercmake/git/nodes/epa_extract_command A test has been implemented. Run git diff master epa_extract_command to see the changes, which are not really that important. The reason I implemented this feature is I want to download and use the Microsoft HTML Help Compiler. As it's a self-extracting ZIP file with a .exe extension, ExternalProject refused to download it because it didn't know how to extract it. I have applied for git access but I am not sure whether I have done that correctly. Specifically, I don't understand the ...After you have been invited... in http://www.cmake.org/Wiki/CMake/Git/Account#Git (who would know I need an invitation!? where should I request such an invite?) Please tell me if I need to do something more to get access to the staging area of git://cmake.org. Thank you -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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 CMake 3.0
On Mon, Oct 14, 2013 at 5:05 PM, Brad King brad.k...@kitware.com wrote: On 10/13/2013 6:03 AM, Alexander Neundorf wrote: * New quoting syntax: Lua-style long-brackets. Quoting opens with [ followed by zero or more = followed by [ and closes with ] followed by the same number of = followed by ]. What's the purpose of the = between the square brackets ? One can choose a unique number of = to match an opening and closing bracket so that the closing bracket is known not to appear in the enclosed content. This avoids the need for any escaping even when closing brackets other lengths appear in the content. This is commonly known as here document http://en.wikipedia.org/wiki/Here_document -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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] CPack: 7-zip generator
On Fri, Oct 11, 2013 at 5:40 PM, Alexander Neundorf neund...@kde.orgwrote: The thread looks somewhat unfinished, and Ralf simply didn't seem to reply anymore, it would have needed just some more pushing to get it in. What kind of pushing? Code polishing? Documentation? Tests? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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] CPack: 7-zip generator
Hello, A few years ago, Ralf Habacker proposed and implemented a 7-zip generator for CPack: http://marc.info/?l=cmakem=124031321521852w=2 Despite positive review from Alexander Neundorf, it seems it was not included. Was there any reason for that? In a project I'm working on currently, 7-zip vs ZIP makes a 3.5 to 1 difference in compressed size. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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
be downloaded with file(DOWNLOAD), the rest of my use of ExternalProject.cmake should be okay for build_projects (where I have discovered that many downloadable source tarballs are in the *.tar.xz form). 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.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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
Hello,
Sorry, the example was wrong (copy paste from a bad revision). This is
the right one:
ExternalProject_Add( graphicsmagick
DOWNLOAD_NAME graphicsmagick.exe
DOWNLOAD_DIR ${WINST_BASEDIR}/downloads
URL ${graphicsmagick_URL}
URL_MD5 ${graphicsmagick_MD5}* EXTRACT_COMMAND
DOWNLOAD_DIRgraphicsmagick.exe /VERYSILENT /NORESTART
/DIR=\${WINST_PREFIX}/bin\ /NOICONS /SP-*
LOG_DOWNLOAD 1
LOG_UPDATE 1
LOG_CONFIGURE 1
LOG_BUILD 1
LOG_TEST 1
LOG_INSTALL 1
)
On Fri, Jul 12, 2013 at 1:48 AM, Pau Garcia i Quiles
pgqui...@elpauer.orgwrote:
Hello,
Related to this, I implemented an EXTRACT_COMMAND option to
ExternalProject_Add which would enable to download anything, provided that
an EXTRACT_COMMAND is also passed so that CMake knows how to extract what
it downloaded. It is specially useful for Windows, where NSIS,
InstallShield, etc can be extracted silently but they all have the .exe /
.msi extension.
It's available from here:
https://elpauer.assembla.com/code/elpauercmake/git/nodes/epa_extract_command
Branch epa_extract_command
(that clone is a bit outdated, btw)
It's used like this:
ExternalProject_Add( graphicsmagick
DOWNLOAD_NAME graphicsmagick.exe
DOWNLOAD_DIR ${WINST_BASEDIR}/downloads
URL ${graphicsmagick_URL}
URL_MD5 ${graphicsmagick_MD5}
*EXTRACT_COMMAND ${CMAKE_COMMAND} -E copy
${WINST_BATDIR}/patches/graphicsmagick.exe.manifest ${WINST_PREFIX}/bin/*
LOG_DOWNLOAD 1
LOG_UPDATE 1
LOG_CONFIGURE 1
LOG_BUILD 1
LOG_TEST 1
LOG_INSTALL 1
)
On Fri, Jul 12, 2013 at 1:30 AM, Alan W. Irwin
ir...@beluga.phys.uvic.cawrote:
These commands
file(DOWNLOAD
http://download.gnome.org/**sources/glib/2.32/glib-2.32.1.**tar.xzhttp://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
with a zero-length cmake_downloaded_glib-2.32.1.**tar.xz produced.
Yet when I use wget to obtain
http://download.gnome.org/**sources/glib/2.32/glib-2.32.1.**tar.xzhttp://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xzthere
are no problems. i.e.,
software@raven wget http://download.gnome.org/**
sources/glib/2.32/glib-2.32.1.**tar.xzhttp://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz
--2013-07-11 16:04:21-- http://download.gnome.org/**
sources/glib/2.32/glib-2.32.1.**tar.xzhttp://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz
Resolving download.gnome.org (download.gnome.org)... 209.132.180.168,
209.132.180.180
Connecting to download.gnome.org
(download.gnome.org)|209.132.**180.168|:80...
connected.
HTTP request sent, awaiting response... 302 Found
Location: https://download.gnome.org/**sources/glib/2.32/glib-2.32.1.**
tar.xz
https://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz[following]
--2013-07-11 16:04:21-- https://download.gnome.org/**
sources/glib/2.32/glib-2.32.1.**tar.xzhttps://download.gnome.org/sources/glib/2.32/glib-2.32.1.tar.xz
Connecting to download.gnome.org
(download.gnome.org)|209.132.**180.168|:443...
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://ftp.gnome.org/pub/**GNOME/sources/glib/2.32/glib-**
2.32.1.tar.xzhttp://ftp.gnome.org/pub/GNOME/sources/glib/2.32/glib-2.32.1.tar.xz[following]
--2013-07-11 16:04:22-- http://ftp.gnome.org/pub/**
GNOME/sources/glib/2.32/glib-**2.32.1.tar.xzhttp://ftp.gnome.org/pub/GNOME/sources/glib/2.32/glib-2.32.1.tar.xz
Resolving ftp.gnome.org (ftp.gnome.org)... 130.239.18.137,
130.239.18.138, 130.239.18.163, ...
Connecting to ftp.gnome.org (ftp.gnome.org)|130.239.18.**137|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 6138200 (5.9M) [application/x-xz]
Saving to: `glib-2.32.1.tar.xz.1'
100%[=**==**]
6,138,200956K/s in 12s
2013-07-11 16:04:35 (508 KB/s) - `glib-2.32.1.tar.xz.1' saved
[6138200/6138200]
If I do the equivalent CMake commands above for some random *.tar.gz
the result was
-- [download 25% complete]
-- [download 100% complete]
-- Download status = 0;no error
with a full file downloaded.
So I don't think I have any syntax error in the above CMake logic.
One explanation is CMake might be having trouble with the http
protocol when there is a tar.xz suffix on the URL. To check that
hypothesis, I also tried downloading
http://download.gnome.org/**sources/gcr/3.4/gcr-3.4.1.tar.**xzhttp://download.gnome.org/sources/gcr/3.4/gcr
[cmake-developers] FOSDEM CrossDesktop DevRoom 2013 - Call for Talks
Hello, The Call for Talks for the CrossDesktop DevRoom at FOSDEM 2013 is now officially open. Please do not wait till the last minute! --8--- * FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the CrossDesktop DevRoom, which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperativity amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE, Windows, Mac OS X, general desktop matters, applications that enhance desktops and web (when related to desktop). Talks can be very specific, such as developing mobile applications with Qt Quick; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2012 schedule might give you some inspiration: https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html Please include the following information when submitting a proposal: - Your name - The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects) - Short abstract of one or two paragraphs - Short bio - Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. The deadline for submissions is December 14th 2012. FOSDEM will be held on the weekend of 2-3 February 2013. Please submit your proposals to crossdesktop-devr...@lists.fosdem.org (subscribtion page for the mailing list: https://lists.fosdem.org/listinfo/crossdesktop-devroom ) -- The CrossDesktop DevRoom 2013 Organization Team* --8--- -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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] visual studio usage
On Fri, Jun 8, 2012 at 6:26 PM, Óscar Fuentes o...@wanadoo.es wrote: J Decker d3c...@gmail.com writes: I mean using cmake --build . and/or getting BUILD_COMMAND from cmake which comes back as devenv which is then used to build projects. I had a bunch of cmake projects that built from a batch file, then I made a cmakelists that does the same thing, so I have one cmakelists.txt which builds all other top level cmakelists. cmake -DCMAKE_MAKE_PROGRAM=msbuild . ? Sometimes that will fail due to the different way msbuild and devenv compute project dependencies. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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] slow regex implementation in RegularExpression
Hi, If it's of any help, I used the pcrecpp library by Google (it's part of PCRE). With pcrecpp, most operations were only 1-3 lines long. The only problem I found is PCRE provided no way to get the previous/next match, which CMake needs. On Tue, Nov 15, 2011 at 4:25 PM, Alexandru Ciobanu a...@rogue-research.com wrote: Hi Bill and Pau, I am currently working on adding PCRE to CMake. Chances are very hight that it will work, given the very similar comp()/exec() API calls in both implementations. I'll let you know about the results soon. Alex On 2011-11-14, at 10:31 PM, Bill Hoffman wrote: On 11/14/2011 6:08 PM, Pau Garcia i Quiles wrote: Bill, I think the current incarnation of regexps in CMake should be kept for compatibility reasons. Yes, of course. Adding PCRE is not difficult, just time consuming. The implementation I'd do would be an additional abstraction layer: - For the current BRE implementation, it would be a 1:1 call match - For the PCRE implementation, it would keep match status, count, next/previous iterators, etc. So, for this case I would be interested to here from Alex to see if swapping out the regex will fix the ctest performance issue. It is a nice isolated place to give PCRE a try. -Bill -- 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 -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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] slow regex implementation in RegularExpression
Bill, I think the current incarnation of regexps in CMake should be kept for compatibility reasons. Adding PCRE is not difficult, just time consuming. The implementation I'd do would be an additional abstraction layer: - For the current BRE implementation, it would be a 1:1 call match - For the PCRE implementation, it would keep match status, count, next/previous iterators, etc. On Mon, Nov 14, 2011 at 7:30 PM, Bill Hoffman bill.hoff...@kitware.comwrote: Sorry for the top post... However, if the issue with ctest being slow can be fixed by using PCRE in CMake, that is good news. We can just link in the library, and replace that small part of CMake internal code that has the performance problem. This should not break backwards compatibility. It also gives us a way to slowly bring in PCRE into CMake. Alex, is there a way you can try PCRE in CMake to see if it fixes the problem? -Bill On 11/14/2011 1:13 PM, Pau Garcia i Quiles wrote: Hi, Check this: A wish a day 11: Perl Compatible Regular Expressions in CMake http://www.elpauer.org/?p=684 Unfortunately the student turned out to be a total fraud: he knew nothing about CMake, regular expressions (much less PCRE!), git, and could barely manage with C/C++. After months of explaining *really* basic stuff (such as the difference between a static and a shared library), he silently gave up. I do have an initial implementation and extensive information on how to implement PCRE in CMake. It's just I don't have enough spare time to do that, and at work I cannot justify investing so many time in CMake for free (for now, we don't need advanced regular expressions) On Mon, Nov 14, 2011 at 6:57 PM, Alexandru Ciobanu a...@rogue-research.com mailto:alex@rogue-research.**coma...@rogue-research.com wrote: Hi, Our team is affected by issue 0012381, that causes extremely poor performance by CTest. Details here: http://public.kitware.com/Bug/**view.php?id=12381http://public.kitware.com/Bug/view.php?id=12381 I've created a small test case that demonstrates the problem. Please find the .cpp file attached. From what I see, the RegularExpression class uses Henry Spencer regex implementation, which is known to be slow for some cases. On my machine, the attached example runs in 0.8 sec. Just to process one string! $ time ./repr real 0m0.865s user 0m0.862s sys 0m0.002s Grep can process 100k such strings in 0.5 sec (which includes reading a 570MB file from disk): $ wc -l big.str.txt 10 big.str.txt $ ls -lh big.str.txt -rw-r--r-- 1 alex staff 572M 14 Nov 12:30 big.str.txt $ time grep ([^:]+): warning[ \t]*[0-9]+[ \t]*: big.str.txt real 0m0.525s user 0m0.255s sys 0m0.269s I see three ways to fix this problem: A) use a trusted 3rd party regex library, like re2 or pcre B) find another self-contained regex implementation C) try to use the standard POSIX regex available in regex.h on most systems I tried to find another self-contained regex implementation, that we could use. I found Tiny REX, but it is as slow, in this case, as Henry Spencer's implementation. So what do you think is the best way to proceed about this problem? sincerely, Alex Ciobanu -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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] rc compiler on windows mingw
Hi, That log looks odd to me. The guy is talking about NetBeans, yet the log shows he is using MinGW from QtCreator 2.3.0? QtCreator's MinGW distribution ships windres.exe Nuwen ships windres.exe TDM ships windres.exe mingw-w64 ships windres.exe I'd say the problem is he has several make.exe in path. One of them comes from Qt Creator's MinGW, the other maybe comes from Strawberry Perl, msysgit, etc. I have been in such an scenario. It may also be that his MinGW installation does not contain windres.exe (maybe because he is using the original mingw32 from mingw.org, which is quite confusing to install and requires several manual steps), but him using Qt Creator, I doubt it. Naming may also be a problem: depending on what build you download from mingw-w64, the RC compiler is called windres.exe or has a funny name such as x86_64-w64-mingw32-windres.exe (which CMake does not find, IIIRC). In summary, I think this guy's system is a bit messed up. On Thu, Sep 22, 2011 at 3:32 PM, Bill Hoffman bill.hoff...@kitware.comwrote: This is not the first time this has come up: http://forums.netbeans.org/**post-115308.htmlhttp://forums.netbeans.org/post-115308.html CMake Error: your RC compiler: CMAKE_RC_COMPILER-NOTFOUND was not found. Please set CMAKE_RC_COMPILER to a valid compiler path or name. Does the rc compiler not always ship with mingw? I think we added support for it about 6 months ago. Thoughts on this? -Bill __**_ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] rc compiler on windows mingw
On Thu, Sep 22, 2011 at 4:42 PM, Bill Hoffman bill.hoff...@kitware.comwrote: This guy thinks he solved the issue by adding cl.exe to the path. If my conjecture is correct, it was not cl.exe what was missing actually, but rc.exe, which happens to live in the same directory as cl.exe. By adding cl.exe to the path he actually added rc.exe to the path, which is what CMake was looking for. Yes, that is exactly what happened in this case. However, the result was the same, he tried to build a project that most likely did not use resources, and it failed. If you try the messed-up scenario I described, you will notice trying to find the resource compiler actually clarifies the situation. In the messed up scenario, you will end up having make, gcc, ld, etc, all coming from different third-party components (msysgit, Strawberry Perl, MinGW, Subversion, etc), but they will not be able to produce an executable, or if they do, it will probably not run because it would have been linked to a different version of some library. This happened to me when I had Strawberry + msysgit + Qt Creator + WANDisco Subversion + OpenSSL-Win32: CMake found all components, yet the executable ended up being linked to a something that was not the first result in the path. How does making the resource compiler mandatory help? Because third parties that contains some elements from the GNU toolchain generally do not contain windres, and if they do, somehow CMake ends up picking up an incompatible combination of make, gcc, ld and windres. In this case, most likely we need to do a different association here... gcc - windres cl - rc.exe And not depend on the build tool. I agree -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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] PCRE
Hi, Just a quick note to let you Debajyoti Datta will be implementing Perl-compatible Regular Expression support in CMake starting next Friday. I am mentoring him in Season of KDE (kind of Google Summer of Code, but for KDE). Some details of what he will be doing here here: http://www.elpauer.org/?p=684 I've just sent him a long e-mail with the technical details and the source of my half-baked implementation. If you are interested in those details too, just ask me and I'll forward the e-mail. We will not be replacing the current regex support in CMake but only adding PCRE in addition to the current regex support. Wherever you find now regex support, there will be also PCRE support. I have been trying to do this for years (!!!) but I never found enough spare time to complete it. Debajyoti will introduce himself here soon and the technical issues will be discussed here, so that other developers can also give him some insight. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Kind-of standard way to support also in-project find-modules
On Tue, Jan 11, 2011 at 11:55 PM, Brad King brad.k...@kitware.com wrote:
Typically we use code of this form:
if(FOO_USE_SYSTEM_BAR)
find_package(BAR)
else()
add_subdirectory(bar)
set(BAR_INCLUDE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/bar/include)
set(BAR_LIBRARY_DIRS ...)
# ...set rest of variables normally provided by FindBAR.cmake
endif()
What about something like this?
if( FOO_USE_LOCAL_BAR)
set( CMAKE_PREFIX_PATH ${PROJECT_SOURCE_DIR}/3rdparty )
endif(FOO_USE_LOCAL_BAR)
find_package(BAR)
It searches the local directory first, then goes for system. Looks easier to me.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Kind-of standard way to support also in-project find-modules
On Wed, Jan 12, 2011 at 12:18 AM, Brad King brad.k...@kitware.com wrote:
On 01/11/2011 06:13 PM, Pau Garcia i Quiles wrote:
What about something like this?
if( FOO_USE_LOCAL_BAR)
set( CMAKE_PREFIX_PATH ${PROJECT_SOURCE_DIR}/3rdparty )
endif(FOO_USE_LOCAL_BAR)
find_package(BAR)
It searches the local directory first, then goes for system. Looks easier to
me.
The FindBAR.cmake module is looking for a binary installation of BAR,
as in lib/libbar.a or bin/bar. The source tree does not provide
this so is not an appropriate place to look.
Oh, OK. I thought this was for the case you want to distribute the
third-party binaries you use to develop your application (we do that
internally).
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
