[CMake] echo in execute_process
in an execute_process() function with ${ECHO} (/bin/echo)what does one
set for WORKING_DIRECTORY?
___
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://www.cmake.org/mailman/listinfo/cmake
[CMake] How to submit new modules?
Hi, I have collected a few modules: FindDL.cmake FindGDAL.cmake FindGeoTIFF.cmake FindMySQL.cmake FindOracle.cmake FindPostgreSQL.cmake FindPROJ4.cmake FindSpatialIndex.cmake FindSQLite3.cmake Perhaps CMake would find some of them useful. Some are already in CMake like FindGDAL.cmake, but in my module I support a few interesting features, like finding GDAL in official distribution of OSGeo4W (http://trac.osgeo.org/osgeo4w/) on Windows. Perhaps a merge would be beneficial. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to submit new modules?
On 24/12/10 00:02, Mateusz Loskot wrote: > Hi, > > I have collected a few modules: > FindDL.cmake > FindGDAL.cmake > FindGeoTIFF.cmake > FindMySQL.cmake > FindOracle.cmake > FindPostgreSQL.cmake > FindPROJ4.cmake > FindSpatialIndex.cmake > FindSQLite3.cmake > > Perhaps CMake would find some of them useful. > > Some are already in CMake like FindGDAL.cmake, but in my module > I support a few interesting features, like finding GDAL > in official distribution of OSGeo4W (http://trac.osgeo.org/osgeo4w/) > on Windows. Perhaps a merge would be beneficial. I completely forgot to point where the modules are stored: https://github.com/mloskot/cmake-modules/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 23 December 2010 22:05, David Cole wrote: > Much easier on the eyes, much nicer in every respect except there's one > extra file in your source tree now. Small price to pay for readability and > future maintainability... Agreed. I think what would be even nicer would be to be able to do common tasks using INSTALL(SOMETHING) to e.g. run fixup for you without having to use another script or INSTALL(CODE). -- Mike McQuaid http://mikemcquaid.com ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On Thu, Dec 23, 2010 at 3:59 PM, KC Jones wrote:
> > Thanks for your comments and questions. May we quote you on that? ("cmake
> is elegant in the extreme ... great tool")
>
> Of course. Since all the code I work with is published on multiple OSes,
> cmake is a godsend. I'm actively working on replacing as much of our legacy
> build methods with cmake solutions. The cmake basics have come relatively
> easily to me. CPack is another story.
>
> Once I get through to the end of this tunnel and have learned CPack well
> enough, I hope to be in a position to offer more constructive contributions
> to easing this learning curve. But, like the problem you describe where
> there is never time for docs and never enough docs, the reality is that when
> my builds are humming, there will be other tasks waiting -- and the task of
> 'giving back to the community' somehow never rises to the top of the stack.
>
> One thought that is jangling around in my head right now:
>
> WRT install(CODE ...) quoting, would it be useful to support the ruby "here
> document" syntax?
>
> install(CODE fixup_bundle("${APPS}" "${QTPLUGINS}" "${DIRS}")
> xxx
>COMPONENT Runtime)
>
> Or is variable substitution at cmake execution time more the rule than the
> exception?
>
>
I think we've somehow favored install(CODE way too much over install(SCRIPT
in the examples that we *do* have.
If there are serious readability problems with any install(CODE chunk
because of excessive escaping required, it should be in its own file where
it does not need to be escaped, (even if it's only 1, 2 or 3 lines), and
then install(SCRIPT can simply include the file in the very same place where
the CODE would have been generated.
So have a file, InstallBundle.cmake whose contents are:
include(BundleUtilities)
fixup_bundle("${APPS}" "${QTPLUGINS}" "${DIRS}")
And then use:
install(SCRIPT ${CMAKE_CURRENT_SOURCE_DIR}/InstallBundle.cmake COMPONENT
Runtime)
Much easier on the eyes, much nicer in every respect except there's one
extra file in your source tree now. Small price to pay for readability and
future maintainability...
HTH,
David
___
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://www.cmake.org/mailman/listinfo/cmake
[CMake] Wrong escaping of custom-command arguments?
Hi, it seems that cmake doesn't properly escape the commandlines for custom commands. I'm adding a list of strings which include whitespace and also parenthesis "()" as arguments to a custom command. Additionally this custom command is running a target built by the same project. Unfortunately CMake only escapes the whitespace, but doesn't escape the parenthesis. Hence invoking the command aborts with a /bin/sh: Syntax error: Bad function name Trying to solve this by quoting the individual arguments using \" doesn't help as cmake still adds a \ before any whitespace. This leads to wrong arguments being given to the actual command and hence it doesn't behave as it should. So anybody got another idea how to get these arguments through properly? BTW: Using VERBATIM doesn't help either (I didn't expect it anyway, but was worth a try). Andreas -- You will experience a strong urge to do good; but it will pass. ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
> Thanks for your comments and questions. May we quote you on that? ("cmake is
> elegant in the extreme ... great tool")
Of course. Since all the code I work with is published on multiple OSes, cmake
is a godsend. I'm actively working on replacing as much of our legacy build
methods with cmake solutions. The cmake basics have come relatively easily to
me. CPack is another story.
Once I get through to the end of this tunnel and have learned CPack well
enough, I hope to be in a position to offer more constructive contributions to
easing this learning curve. But, like the problem you describe where there is
never time for docs and never enough docs, the reality is that when my builds
are humming, there will be other tasks waiting -- and the task of 'giving back
to the community' somehow never rises to the top of the stack.
One thought that is jangling around in my head right now:
WRT install(CODE ...) quoting, would it be useful to support the ruby "here
document" syntax?
install(CODE
[CMake] Modules with additional files
Hey,
I've got a library that provides several cmake modules and also uses
them. Some of these modules have additional files, e.g. to be used with
CONFIGURE_FILE. The question is, how do I locate these additional files
so that they work in both cases, in project and installed?
${CMAKE_ROOT}/Modules is of course not working and is also a bad
assumption for multi-user systems where not everyone is admin. Something
like CMAKE_CURRENT_MODULE_DIR would be ideal for my case... Is there a
general solution for this problem?
Thanks for helping,
Johannes
signature.asc
Description: OpenPGP digital signature
___
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://www.cmake.org/mailman/listinfo/cmake
[CMake] Copying some files using CMake
-- Forwarded message -- From: John Drescher Date: Thu, Dec 23, 2010 at 12:03 PM Subject: Re: [CMake] Copying some files using CMake To: Stormwind Dev On Thu, Dec 23, 2010 at 11:53 AM, Stormwind Dev wrote: > Thanks for your reply John. There is one question left about your GetRuntime > module. The files you copy are located within the CMake directory in your > root source dir, right? > No only the CMake modules are in that folder. The files I copy are from the binary folders where I have Qt and qwt built. The other two modules get the paths using variables defined in the finders for each package. And the final batch file ends up being created in the project's binary folder. If you have Qt installed on your system I can send you a small full project example that I used to develop these cmake modules. John ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying some files using CMake
Thanks for your reply John. There is one question left about your
GetRuntime module. The files you copy are located within the CMake
directory in your root source dir, right?
Best Michael
Am 23.12.2010 17:28, schrieb John Drescher:
On Thu, Dec 23, 2010 at 11:18 AM, Stormwind Dev
wrote:
Dear List,
I've got a question on copying some files from one directory to another
using CMake.
Let's say, I got some libraries collected in a special directory. I want
CMake to copy these libs to the distribution directory of my project. Using
add_custom_command, I managed to have CMake copy my .exe to the distribution
directory, but when I try to do this for my libraries something goes
terribly wrong.
add_custom_command( TARGET MagicRPG POST_BUILD
COMMAND copy \"$(TargetPath)\" .\\dist\\bin )
is what I did to copy my exe. When I use this
add_custom_command( TARGET MagicRPG POST_BUILD
COMMAND copy \"$(TargetPath)\" \"${SDKS_BASE_DIR}/SDL/lib/SDL.dll\"
.\\dist\\bin)
to get SDL.dll copied to dist/bin Visual Studio fails with message
Fehler1error MSB3073: Der Befehl "copy
"D:\Projekte\cpp\games\Magic\bin\Debug\MagicRPG.exe"
"D:/SDKs/SDL/lib/SDL.dll" .\dist\bin
if errorlevel 1 goto VCReportError
:VCEnd" wurde mit dem Code 1 beendet.C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets1136
MagicRPG
Can anybody please help me with the right syntax for copying multiple files
at POST_BUILD?
Attached are 3 CMake modules I use for this. One is a macro that
builds a batch file that ends up being a target in visual studio.
I put them in a CMake folder inside my root source folder and have the
following line in my main CMakeLists.txt
include(${PROJECT_SOURCE_DIR}/CMake/GetRuntime.cmake)
this brings in the macro with support for generating the batch file
and GetRuntime target.
Then later in the main CMakeLists.txt file I use the other two modules.
FIND_PACKAGE( Qt4 REQUIRED )
set(QT_USE_QTNETWORK true)
set(QT_USE_QTSQL true)
set(QT_USE_QTXML true)
INCLUDE( ${QT_USE_FILE} )
include(${PROJECT_SOURCE_DIR}/CMake/GetQtRuntime.cmake)
IF(USE_QWT)
FIND_PACKAGE(Qwt REQUIRED)
INCLUDE_DIRECTORIES(${QWT_INCLUDE_DIR})
include(${PROJECT_SOURCE_DIR}/CMake/GetQwtRuntime.cmake)
set (UPMC_EXTERNAL_LIBS ${UPMC_EXTERNAL_LIBS} ${QWT_LIBRARIES})
ENDIF(USE_QWT)
John
___
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 12/23/2010 9:59 AM, Mike McQuaid wrote: A few questions: What platforms does it need to be tested on? At least one. The important thing is that it actually has a test, that will be run with make test on CMake after the code is merged into CMake. The dashboards will take care of testing it on platforms you don't have. We are also working on some interesting stuff in this area as well: http://www.kitware.com/products/html/TheCDashHomeCloud.html What branch should you base it off? master http://www.cmake.org/Wiki/CMake/Git#Branches There is also this article that we did on DVCS that might give some insight on our thoughts: http://www.kitware.com/products/html/DistributedVersionControlTheFutureOfHistory.html Great, I think I understand how to do that a bit better now. It would be great if the contents of your email above was included here: http://www.cmake.org/cmake/project/getinvolved.html and also possibly on your Github/Gitorious pages. Yes, much of this is new stuff, so it has not yet made it to that page yet. I have been thinking about the issues you brought up for some time now, and have not yet written them down. Thanks for the comprehensive reply and sorry for any criticism from my misunderstandings above. Thanks for the post, I am glad that it is more of a "documentation" bug than a process issue. Being on the "inside", I of course know what I and the other CMake developers are thinking. It is easy to fall into the trap of thinking that everyone knows what you know... Although sometimes having stuff on web pages is not enough (existence of cmake-developers case in point...). However, the "how to get code into CMake" is not documented anywhere yet Thanks, and I look forward to you contributions! -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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying some files using CMake
On Thu, Dec 23, 2010 at 11:18 AM, Stormwind Dev
wrote:
> Dear List,
>
> I've got a question on copying some files from one directory to another
> using CMake.
>
> Let's say, I got some libraries collected in a special directory. I want
> CMake to copy these libs to the distribution directory of my project. Using
> add_custom_command, I managed to have CMake copy my .exe to the distribution
> directory, but when I try to do this for my libraries something goes
> terribly wrong.
>
> add_custom_command( TARGET MagicRPG POST_BUILD
> COMMAND copy \"$(TargetPath)\" .\\dist\\bin )
>
> is what I did to copy my exe. When I use this
>
> add_custom_command( TARGET MagicRPG POST_BUILD
> COMMAND copy \"$(TargetPath)\" \"${SDKS_BASE_DIR}/SDL/lib/SDL.dll\"
> .\\dist\\bin)
>
> to get SDL.dll copied to dist/bin Visual Studio fails with message
>
> Fehler 1 error MSB3073: Der Befehl "copy
> "D:\Projekte\cpp\games\Magic\bin\Debug\MagicRPG.exe"
> "D:/SDKs/SDL/lib/SDL.dll" .\dist\bin
> if errorlevel 1 goto VCReportError
> :VCEnd" wurde mit dem Code 1 beendet. C:\Program Files
> (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets 113 6
> MagicRPG
>
> Can anybody please help me with the right syntax for copying multiple files
> at POST_BUILD?
>
Attached are 3 CMake modules I use for this. One is a macro that
builds a batch file that ends up being a target in visual studio.
I put them in a CMake folder inside my root source folder and have the
following line in my main CMakeLists.txt
include(${PROJECT_SOURCE_DIR}/CMake/GetRuntime.cmake)
this brings in the macro with support for generating the batch file
and GetRuntime target.
Then later in the main CMakeLists.txt file I use the other two modules.
FIND_PACKAGE( Qt4 REQUIRED )
set(QT_USE_QTNETWORK true)
set(QT_USE_QTSQL true)
set(QT_USE_QTXML true)
INCLUDE( ${QT_USE_FILE} )
include(${PROJECT_SOURCE_DIR}/CMake/GetQtRuntime.cmake)
IF(USE_QWT)
FIND_PACKAGE(Qwt REQUIRED)
INCLUDE_DIRECTORIES(${QWT_INCLUDE_DIR})
include(${PROJECT_SOURCE_DIR}/CMake/GetQwtRuntime.cmake)
set (UPMC_EXTERNAL_LIBS ${UPMC_EXTERNAL_LIBS} ${QWT_LIBRARIES})
ENDIF(USE_QWT)
John
GetRuntime.cmake
Description: Binary data
GetQtRuntime.cmake
Description: Binary data
GetQwtRuntime.cmake
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://www.cmake.org/mailman/listinfo/cmake
[CMake] Copying some files using CMake
Dear List,
I've got a question on copying some files from one directory to another
using CMake.
Let's say, I got some libraries collected in a special directory. I want
CMake to copy these libs to the distribution directory of my project.
Using add_custom_command, I managed to have CMake copy my .exe to the
distribution directory, but when I try to do this for my libraries
something goes terribly wrong.
add_custom_command( TARGET MagicRPG POST_BUILD
COMMAND copy \"$(TargetPath)\" .\\dist\\bin )
is what I did to copy my exe. When I use this
add_custom_command( TARGET MagicRPG POST_BUILD
COMMAND copy \"$(TargetPath)\"
\"${SDKS_BASE_DIR}/SDL/lib/SDL.dll\" .\\dist\\bin)
to get SDL.dll copied to dist/bin Visual Studio fails with message
Fehler1error MSB3073: Der Befehl "copy
"D:\Projekte\cpp\games\Magic\bin\Debug\MagicRPG.exe"
"D:/SDKs/SDL/lib/SDL.dll" .\dist\bin
if errorlevel 1 goto VCReportError
:VCEnd" wurde mit dem Code 1 beendet.C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets113
6MagicRPG
Can anybody please help me with the right syntax for copying multiple
files at POST_BUILD?
Best
Michael
___
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Qt on Windows 7 MinGW
Am 23.12.2010 12:39, schrieb Lukas Woodtli: Everything builds without error. But if I launch my application I get an error : The procedure entry point _Z17qt_message_output9QtMsgTypePKc could not be located in the dynamic link library QtCore4.dll It's a common problem - you're using the wrong QtCore4.dll Christian ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 23 December 2010 14:47, Michael Wild wrote: > Well, I also did some contributions to homebrew, and I have to agree > that patches get picked up really quickly. There's one big "but", > though: Writing a formula is fairly simple. Just copy an existing > formula that is similar to your favourite package, adapt it, build, > commit and push. Many contributions are even much simpler: just update > the version number, done. The learning curve is extremely low. Also, > Homebrew is Mac-only, so contributors don't have to worry about all the > exotic platforms out there. They are geeks and nerds who like to build > stuff themselves. I'd bet that almost everybody using Homebrew is also > contributing to the formulae, but I'm very sure that only a select few > actually ever even take look into the internals and supply patches to > this part of the project. Yep, good points here, I do agree, I guess I was just trying to be more specific. > I think almost everything that fits into the CMake-picture would get > accepted as long as it meets the quality standards, is documented and > tested. Also, FindXXX.cmake module need a maintainer who commits to > keeping them up-to-date and fixing issues that crop up. Also good to know. > Agreed. Sometimes the response is a bit disappointing. But this probably > also has to do with the fact that one's personal pet-itch isn't as > important to other people as one would like it to be ;-) Sure, I get that from Homebrew too. I guess my point is that an apathetic response is better than none at all. I'll use the developers list for this now though. > That said, I think it has become much easier to contribute than in CVS > times. That was just a PITA. But there certainly is room for > improvement, I agree with that. For one, the Wiki is plain inaccessible. > E.g. above mentioned CMake/Git Wiki page is completely isolated. Nothing > links there! Also, the Git/Workflow/Topic page is only reached from (1) > this isolated CMake/Git page or from the ITK development documentation. > Then, there is a clear lack of documentation on how to prepare a new > test. Looking into the existing tests doesn't really help (at least that > was my impression), as most of the stuff is so convoluted, it takes > hours to pick apart. I would agree with this. There's probably a fair amount of wiki organisation that could be done (which I guess I could help with too) and some of it could be rolled into the main CMake documentation perhaps (such as variable descriptions). I too would love more development/test documentation. -- Mike McQuaid http://mikemcquaid.com ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 23 December 2010 14:30, Bill Hoffman wrote: > Something like this perhaps: > > http://www.cmake.org/cmake/help/mailing.html > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers Excuse my extreme ignorance, I had no idea that existed. Subscribing! > 1. you have some code. > The biggest thing that slows down adoption of new code in CMake is lack of > testing. New features that are not tested, are not welcome into CMake. If > the code has a CMake test and there is good dashboard coverage for the test, > then the code will be adopted much quicker. The code can be done on github > or gitorious.org, or just a patch attached to a bug entry in the CMake bug > tracker. If a cmake developer can just merge in the code, and run ctest to > test the new code, it makes it very easy to commit. Ok, that's good to know. So the basic use-case should be to write the code, write a test that runs it and ensure it's hooked up to ctest, make sure it passes and then make a merge request detailing the above. A few questions: What platforms does it need to be tested on? What branch should you base it off? I wasn't sure if you guys looked at the merge requests on Github/Gitorious, that's good to know. > 2. You have a suggestion for a change but no code. > I think there are two sub-cases for this as well: > A. You are willing to write the code yourself. > B. You think that someone else should write it for you. > > For A, you would want to get buy in from the developers and community before > starting the code. For this the cmake-developers mailing list would be the > place to start. Although, sometimes it might make sense to float the idea > on the cmake mailing list first to see what the community things, and then > use the developers list for implementation details. Ok, great. > For B, you have to do a pretty good sales job for the work to be done. You > are basically asking for a handout. Kitware does not directly invest in > CMake, new features developed by Kitware come from Kitware customers > requesting them. So, you can hire Kitware (become a customer), or if your > suggestion lines up with the needs of an existing customer, you might get > lucky. Of course Kitware people are not the only ones developing CMake, you > might be able to convince someone else to do the work. Either way, this is > the hardest type of change to have made. Sure. I'm not in this group as I'm happy to do the work myself but that's good to know. > 3. After each release we send out and email to the cmake and > cmake-developers list, and ask for people to suggest the things they would > like to see in the next release. Here is the current list: > http://public.kitware.com/Bug/roadmap_page.php. Next release is scheduled > for Jan. 10. Cool, again, good to know. > 4. We have directed all new bugs on the bug tracker to the cmake-developers > list. This allows all developers to see new issues as they come in. > > 5. We have made an effort to clean up old stuff in the bug tracker. > > > So, if you have time that you want to spend on CMake development, join the > cmake-developers mailing list. Write some tested, documented code and > contribute it. Great, I think I understand how to do that a bit better now. It would be great if the contents of your email above was included here: http://www.cmake.org/cmake/project/getinvolved.html and also possibly on your Github/Gitorious pages. Thanks for the comprehensive reply and sorry for any criticism from my misunderstandings above. -- Mike McQuaid http://mikemcquaid.com ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 12/23/2010 02:44 PM, Mike McQuaid wrote: > On 23 December 2010 13:24, David Cole wrote: >> How do we make it very hard? What about KDE and Homebrew make this very >> easy? Specifics, please. > > Firstly, http://producingoss.com/ is a great read. > > Specifically though, Homebrew is pretty much the golden child of > encouraging external contribution. We're the most forked repo on > Github, the 6th most watched and have had 719 code contributors in > about a year and a half of existing. We've managed this with only 4 > people with commit access, all of whom have full-time jobs in the > industry working on other projects. Well, I also did some contributions to homebrew, and I have to agree that patches get picked up really quickly. There's one big "but", though: Writing a formula is fairly simple. Just copy an existing formula that is similar to your favourite package, adapt it, build, commit and push. Many contributions are even much simpler: just update the version number, done. The learning curve is extremely low. Also, Homebrew is Mac-only, so contributors don't have to worry about all the exotic platforms out there. They are geeks and nerds who like to build stuff themselves. I'd bet that almost everybody using Homebrew is also contributing to the formulae, but I'm very sure that only a select few actually ever even take look into the internals and supply patches to this part of the project. With CMake the situation is more complex. You have three distinct user groups: (1) People trying to build the software on their machines. They do not care whether the build system is CMake, SCons, Ant, autohell or just plain Make. They just want it to work. (2) Developers who use CMake as their build system of choice and (3) people from the second group who got annoyed enough by some missing feature or a bug to make the step and contribute a patch. Now, the real complication is that CMake must support a large array of esoteric hardware and operating systems, to which most of the people do not have access to, or even don't know about, so they can't even take a guess at potential problems. Also, if you want to get something into CMake, you have to provide a test and documentation, both of which are tedious and not very attractive tasks. Also, the CMake code base is much, much more involved. There are probably quite a few more issues which make it a lot harder to contribute to CMake than to Homewbrew. > > I think Github and DVCS really allows you to scale well. If you > publish decent guidelines for how people can contribute and use e.g. > pull requests on Github or similar Git mechanisms then you can have > incredibly quick workflows for viewing, mergeing, testing and pushing > user code. That's already there: http://www.cmake.org/Wiki/CMake/Git http://public.kitware.com/Wiki/Git/Workflow/Topic You can also just publish a topic-branch on GitHub and then put a pull-request in the bug-tracker. > > I have an alias "bpi" in my shell which downloads from a pull request > or user repository commit on Github, applies it to my local > repository, shows me the changes and installs the relevant changes > packages. Once I type "git push" this is now shared with everyone > using the project. > > I think for you guys general guidelines on what patches would/wouldn't > be accepted would be a good start. Documentation of your coding > standards and what I should do to test my work before submitting it > would help too. I can guess a fair amount because I've contributed to > a lot of open-source projects but others might not do the same. > I think almost everything that fits into the CMake-picture would get accepted as long as it meets the quality standards, is documented and tested. Also, FindXXX.cmake module need a maintainer who commits to keeping them up-to-date and fixing issues that crop up. > I think the main thing that I find lacking here though is > responsiveness to suggestions. When I make one, I need to keep poking > again and again until I receive I response. Other things include > specific code review of patches and a quick "this functionality > would/wouldn't be accepted" when suggestions are made so I know > whether to work on it or not. Agreed. Sometimes the response is a bit disappointing. But this probably also has to do with the fact that one's personal pet-itch isn't as important to other people as one would like it to be ;-) > > I think using Git/Github in your workflow could help with part of this > but a certain amount will need to be responding to users, either > through your current bug tracker, a better one or Github's issue > tracker. IMHO Github's issue tracker is far below par. CMake uses Mantis which is much more powerful, but likely also not to everybody's liking. It certainly is a bit more complicated to submit a bug report in Mantis than in the Github tracker. > > Another option that might help is a cmake-dev mailing list that is > only for discussing development issues rath
Re: [CMake] CPack 101
Hi Mike and all, On Thu, Dec 23, 2010 at 21:58, Mike McQuaid wrote: > On 23 December 2010 12:43, David Cole wrote: > I think the main problem is that you make it very hard for people to > contribute. KDE and Homebrew (two other open-source projects I've > written a lot of code for over the years) make this very easy. > > Kitware is great, you clearly write good code and have done a great > job creating CMake and CPack. They are fantastic tools. However, I > think until you are more encouraging of external developers you will > struggle to make huge improvements to CMake. As only a casual user of CMake, I'm hesitant to enter this kind of thread, but a comment like the above is difficult to ignore. :-) IMHO, the comparison between KDE and CMake is a bit unfair. KDE is visible to many people, both developers and users, while CMake is known by only developers. Also, it is known that CMake is developed by Kitware; this is quite different from KDE which relies on a very large international community. So, combining these two reasons, it is not so surprising that the management of how KDE is developed is more advanced. Yes, they are both open-source, but two software can be both open-source but still be run differently. It isn't necessary for one open-source software to be managed similar to another one. And I think (without knowing the actual numbers) that the code to KDE is larger than CMake? Personally, the help I've seen on this mailing list and in the mailing list archives is great and while there may be room for improvement, I guess it can happen in time. > The mailing list is OK but most people don't want to sign up to a > mailing list and receive lots of emails that have nothing to do with > them. I'm only signed up because I want to try and get some patches > merged and was told that I should discuss things here rather than the > bugtracker. > > I hope I don't cause any offense here either. I'm passionate about > CMake because I like the tool and want to make it better. Someone else has talked about using Google on the archives. An often ignored point is that thanks to Google, you can "contribute" to the documentation just by writing a web page. If it is useful and gets linked by others, etc., then the right keywords will make your web page appear on the first page of Google's results. Some of the help I've got on CMake, CPack, etc. are on non-cmake pages, actually. Of course, if these pages are wrong, then the error propagates... But if it is useful, I guess Kitware developers will be happy to include it in the Wiki at least? Ray ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 12/23/2010 8:44 AM, Mike McQuaid wrote: On 23 December 2010 13:24, David Cole wrote: How do we make it very hard? What about KDE and Homebrew make this very easy? Specifics, please. I think for you guys general guidelines on what patches would/wouldn't be accepted would be a good start. Documentation of your coding standards and what I should do to test my work before submitting it would help too. I can guess a fair amount because I've contributed to a lot of open-source projects but others might not do the same. I think the main thing that I find lacking here though is responsiveness to suggestions. When I make one, I need to keep poking again and again until I receive I response. Other things include specific code review of patches and a quick "this functionality would/wouldn't be accepted" when suggestions are made so I know whether to work on it or not. I think using Git/Github in your workflow could help with part of this but a certain amount will need to be responding to users, either through your current bug tracker, a better one or Github's issue tracker. Another option that might help is a cmake-dev mailing list that is only for discussing development issues rather than users seeking help. Something like this perhaps: http://www.cmake.org/cmake/help/mailing.html http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers The way I see it, there are two types of contributions. 1. You have already written some code that does something you need for your project. 2. You have a suggestion for a change that you would like to see but have not done. These two cases are treated differently. Here is the workflow I would would like to see for them: 1. you have some code. The biggest thing that slows down adoption of new code in CMake is lack of testing. New features that are not tested, are not welcome into CMake. If the code has a CMake test and there is good dashboard coverage for the test, then the code will be adopted much quicker. The code can be done on github or gitorious.org, or just a patch attached to a bug entry in the CMake bug tracker. If a cmake developer can just merge in the code, and run ctest to test the new code, it makes it very easy to commit. 2. You have a suggestion for a change but no code. I think there are two sub-cases for this as well: A. You are willing to write the code yourself. B. You think that someone else should write it for you. For A, you would want to get buy in from the developers and community before starting the code. For this the cmake-developers mailing list would be the place to start. Although, sometimes it might make sense to float the idea on the cmake mailing list first to see what the community things, and then use the developers list for implementation details. For B, you have to do a pretty good sales job for the work to be done. You are basically asking for a handout. Kitware does not directly invest in CMake, new features developed by Kitware come from Kitware customers requesting them. So, you can hire Kitware (become a customer), or if your suggestion lines up with the needs of an existing customer, you might get lucky. Of course Kitware people are not the only ones developing CMake, you might be able to convince someone else to do the work. Either way, this is the hardest type of change to have made. In summary, Kitware and the CMake developers outside Kitware have been working on being more inclusive. We realize that our process needs to include more of the community. Recently we have made several changes in order to include more outside help on the CMake project. Those changes are as follows: 1. We moved to git 2. We moved to a quarterly release schedule. 3. After each release we send out and email to the cmake and cmake-developers list, and ask for people to suggest the things they would like to see in the next release. Here is the current list: http://public.kitware.com/Bug/roadmap_page.php. Next release is scheduled for Jan. 10. 4. We have directed all new bugs on the bug tracker to the cmake-developers list. This allows all developers to see new issues as they come in. 5. We have made an effort to clean up old stuff in the bug tracker. So, if you have time that you want to spend on CMake development, join the cmake-developers mailing list. Write some tested, documented code and contribute it. Thanks. -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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 23 December 2010 13:24, David Cole wrote: > How do we make it very hard? What about KDE and Homebrew make this very > easy? Specifics, please. Firstly, http://producingoss.com/ is a great read. Specifically though, Homebrew is pretty much the golden child of encouraging external contribution. We're the most forked repo on Github, the 6th most watched and have had 719 code contributors in about a year and a half of existing. We've managed this with only 4 people with commit access, all of whom have full-time jobs in the industry working on other projects. I think Github and DVCS really allows you to scale well. If you publish decent guidelines for how people can contribute and use e.g. pull requests on Github or similar Git mechanisms then you can have incredibly quick workflows for viewing, mergeing, testing and pushing user code. I have an alias "bpi" in my shell which downloads from a pull request or user repository commit on Github, applies it to my local repository, shows me the changes and installs the relevant changes packages. Once I type "git push" this is now shared with everyone using the project. I think for you guys general guidelines on what patches would/wouldn't be accepted would be a good start. Documentation of your coding standards and what I should do to test my work before submitting it would help too. I can guess a fair amount because I've contributed to a lot of open-source projects but others might not do the same. I think the main thing that I find lacking here though is responsiveness to suggestions. When I make one, I need to keep poking again and again until I receive I response. Other things include specific code review of patches and a quick "this functionality would/wouldn't be accepted" when suggestions are made so I know whether to work on it or not. I think using Git/Github in your workflow could help with part of this but a certain amount will need to be responding to users, either through your current bug tracker, a better one or Github's issue tracker. Another option that might help is a cmake-dev mailing list that is only for discussing development issues rather than users seeking help. Just a few ideas for you. Hopefully some of them are useful. I'm more than willing to discuss this in further depth, either here, personal mail or at an open-source conference (next one I'll definitely be at will be the KDE one in Berlin 2011). > Thank you. Even with more external developers, I think we'll struggle -- > that would just be a different sort of struggle. Sure, it will probably involve more reviewing/mentoring but less code writing. > Again, let me stress, no offense taken. There is no way you can offend me, > unless you start calling me names for no reason. Reasonable discussion > always welcome. So can I call you names as long as I have a good reason? ;) -- Mike McQuaid http://mikemcquaid.com ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On Thu, Dec 23, 2010 at 8:23 AM, Johan Björk wrote: > > > On Thu, Dec 23, 2010 at 1:43 PM, David Cole wrote: > >> On Wed, Dec 22, 2010 at 12:57 PM, KC Jones wrote: >> >>> Feeling really uneasy about putting this out there, but here goes... >>> >>> I have an app that I am building with cmake (2.8) on both Mac (10.6.40 >>> and Linux (Ubuntu 10.04). >>> The app depends on some libraries (Qt4.6 (no plugins) and a customized >>> build of Poco). >>> I want to generate a DragAndDrop DMG installer on Mac. (a la macdeployqt >>> + Poco lib packaging) >>> On Linux, I want a Debian package to install the Poco libs at a minimum >>> along with my executable. >>> Equivalent Windows installers will be needed someday. >>> >>> I've reviewed the docs at >>> http://www.cmake.org/cmake/help/cmake-2-8-docs.html >>> I've reviewed bits and pieces on the wiki: >>> http://www.cmake.org/Wiki/BundleUtilitiesExample >>> http://www.cmake.org/Wiki/CMake#CPack >>> >>> And I just don't seem to get it. I know this is very possible. I know >>> this is my own problem, first and foremost. So I'm exposing myself to >>> potential criticism here since RTFM and "get a clue" are probably the >>> biggest part of fixing my problem. Im not really asking for specific help >>> on my code - I might ask for that later. For now I just want to vent, >>> hopefully in a constructive way. >>> >>> I just don't think that CPack documentation and examples as they >>> currently are published are sufficient or effective. >>> >>> >> Neither do we: >> http://public.kitware.com/Bug/view.php?id=10067 >> >> >> A few suggestions: >>> >>>- More CPack example and tutorials would be very helpful. I see from >>>archive searches that I'm not the first to suggest this. The Qt example >>> is >>>great, but the plugin support is overkill for most, and obfuscates much >>> of >>>the rest of the example. >>>- A step-wise tutorial format that starts with a working build, adds >>>install target support, then adds CPack code would help my addled brain. >>> Presenting newbies like me with a fully baked end result is helpful, but >>>somewhat hard to digest. >>>- Separating the docs into different namespaces (Cmake, CPack, >>>CTest...) might be more effective. I struggled a long while before >>> finding >>>the install command docs (which I continue to struggle with). The atomic >>>layout of the docs obscures the module-level relationships. >>>- A glossary, please. For instance "bundle" comes out of OS X, but >>>now has some CMake-specific meaning for Linux and Win that I know is very >>>important to me, but fully incomprehensible in my reading so far. Oh, >>> and >>>what are bundle keys? >>>- More meta docs please. Somewhere in my stumbling I found a decent >>>diagram about how the ExternalProject module works. I think it was on >>> the >>>wiki, but I can't find it now. I would die for something similar that >>> shows >>>what install does and how it integrates with CPack. Same goes for >>>BudleUtilities and other modules I've yet to discover. >>> >>> >> As always, as developers we find ourselves constantly working to improve >> what we have: fixing bugs, implementing new features, answering questions on >> the mailing list, blogging/communicating about it, adding examples and >> suggestions to the Wiki. >> >> The struggle is reserving enough time to contribute to documentation when >> there are always "real" (functional) bugs to be fixed. Perpetual questions: >> what's "enough" documentation?, how do we make sure people can find it >> easily?, how do we name this better (but still preserve the existing names >> for people already using it / backwards compatibility)? >> >> I make no excuses here: yes, the CPack and CTest documentation are lacking >> / lagging behind the CMake documentation. However, it will take a very real >> and concerted and time-consuming effort to improve the situation. With the >> open source nature of the project, we have to be willing to accept the >> organic growth that occurs in the code base: the documentation will be the >> same: it will improve gradually, over time, as contributors are able to >> improve it. >> >> Until then, at least the mailing list has a reasonable response rate and, >> it seems, sufficient participation from knowledgeable folks willing to pitch >> in and answer. So... if you're confused about something, please ask here. >> >> How about a search for the mailinglist archives? > A typical google search about "CMake stuff" yields mailing list discussions as the top hits the vast majority of the time. If you want to search *just* the mailing list archives, use: site:http://www.cmake.org/pipermail/cmake I really, really don't think we can provide you with a better search experience than Google. Just sayin'... Thx, David > >> >>> One final comment, cmake is elegant in the extreme. I can see from some >>> of the wiki pages about ho
Re: [CMake] CPack 101
On Thu, Dec 23, 2010 at 7:58 AM, Mike McQuaid wrote: > On 23 December 2010 12:43, David Cole wrote: > > Neither do we: > > http://public.kitware.com/Bug/view.php?id=10067 > > > As always, as developers we find ourselves constantly working to improve > > what we have: fixing bugs, implementing new features, answering questions > on > > the mailing list, blogging/communicating about it, adding examples and > > suggestions to the Wiki. > > > > The struggle is reserving enough time to contribute to documentation when > > there are always "real" (functional) bugs to be fixed. Perpetual > questions: > > what's "enough" documentation?, how do we make sure people can find it > > easily?, how do we name this better (but still preserve the existing > names > > for people already using it / backwards compatibility)? > > > I make no excuses here: yes, the CPack and CTest documentation are > lacking / > > lagging behind the CMake documentation. However, it will take a very real > > and concerted and time-consuming effort to improve the situation. With > the > > open source nature of the project, we have to be willing to accept the > > organic growth that occurs in the code base: the documentation will be > the > > same: it will improve gradually, over time, as contributors are able to > > improve it. > > I think the main problem is that you make it very hard for people to > contribute. KDE and Homebrew (two other open-source projects I've > written a lot of code for over the years) make this very easy. > > How do we make it very hard? What about KDE and Homebrew make this very easy? Specifics, please. Kitware is great, you clearly write good code and have done a great > job creating CMake and CPack. They are fantastic tools. However, I > think until you are more encouraging of external developers you will > struggle to make huge improvements to CMake. > Thank you. Even with more external developers, I think we'll struggle -- that would just be a different sort of struggle. > > Until then, at least the mailing list has a reasonable response rate and, > it > > seems, sufficient participation from knowledgeable folks willing to pitch > in > > and answer. So... if you're confused about something, please ask here. > > We (I hope I speak for all CMake devs, here) take no offense. We welcome > > discussion, always. > > The mailing list is OK but most people don't want to sign up to a > mailing list and receive lots of emails that have nothing to do with > them. I'm only signed up because I want to try and get some patches > merged and was told that I should discuss things here rather than the > bugtracker. > > I hope I don't cause any offense here either. I'm passionate about > CMake because I like the tool and want to make it better. > > Again, let me stress, no offense taken. There is no way you can offend me, unless you start calling me names for no reason. Reasonable discussion always welcome. Thx, David > -- > Mike McQuaid > http://mikemcquaid.com > ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On Thu, Dec 23, 2010 at 1:43 PM, David Cole wrote: > On Wed, Dec 22, 2010 at 12:57 PM, KC Jones wrote: > >> Feeling really uneasy about putting this out there, but here goes... >> >> I have an app that I am building with cmake (2.8) on both Mac (10.6.40 and >> Linux (Ubuntu 10.04). >> The app depends on some libraries (Qt4.6 (no plugins) and a customized >> build of Poco). >> I want to generate a DragAndDrop DMG installer on Mac. (a la macdeployqt + >> Poco lib packaging) >> On Linux, I want a Debian package to install the Poco libs at a minimum >> along with my executable. >> Equivalent Windows installers will be needed someday. >> >> I've reviewed the docs at >> http://www.cmake.org/cmake/help/cmake-2-8-docs.html >> I've reviewed bits and pieces on the wiki: >> http://www.cmake.org/Wiki/BundleUtilitiesExample >> http://www.cmake.org/Wiki/CMake#CPack >> >> And I just don't seem to get it. I know this is very possible. I know >> this is my own problem, first and foremost. So I'm exposing myself to >> potential criticism here since RTFM and "get a clue" are probably the >> biggest part of fixing my problem. Im not really asking for specific help >> on my code - I might ask for that later. For now I just want to vent, >> hopefully in a constructive way. >> >> I just don't think that CPack documentation and examples as they currently >> are published are sufficient or effective. >> >> > Neither do we: > http://public.kitware.com/Bug/view.php?id=10067 > > > A few suggestions: >> >>- More CPack example and tutorials would be very helpful. I see from >>archive searches that I'm not the first to suggest this. The Qt example >> is >>great, but the plugin support is overkill for most, and obfuscates much of >>the rest of the example. >>- A step-wise tutorial format that starts with a working build, adds >>install target support, then adds CPack code would help my addled brain. >> Presenting newbies like me with a fully baked end result is helpful, but >>somewhat hard to digest. >>- Separating the docs into different namespaces (Cmake, CPack, >>CTest...) might be more effective. I struggled a long while before >> finding >>the install command docs (which I continue to struggle with). The atomic >>layout of the docs obscures the module-level relationships. >>- A glossary, please. For instance "bundle" comes out of OS X, but >>now has some CMake-specific meaning for Linux and Win that I know is very >>important to me, but fully incomprehensible in my reading so far. Oh, and >>what are bundle keys? >>- More meta docs please. Somewhere in my stumbling I found a decent >>diagram about how the ExternalProject module works. I think it was on the >>wiki, but I can't find it now. I would die for something similar that >> shows >>what install does and how it integrates with CPack. Same goes for >>BudleUtilities and other modules I've yet to discover. >> >> > As always, as developers we find ourselves constantly working to improve > what we have: fixing bugs, implementing new features, answering questions on > the mailing list, blogging/communicating about it, adding examples and > suggestions to the Wiki. > > The struggle is reserving enough time to contribute to documentation when > there are always "real" (functional) bugs to be fixed. Perpetual questions: > what's "enough" documentation?, how do we make sure people can find it > easily?, how do we name this better (but still preserve the existing names > for people already using it / backwards compatibility)? > > I make no excuses here: yes, the CPack and CTest documentation are lacking > / lagging behind the CMake documentation. However, it will take a very real > and concerted and time-consuming effort to improve the situation. With the > open source nature of the project, we have to be willing to accept the > organic growth that occurs in the code base: the documentation will be the > same: it will improve gradually, over time, as contributors are able to > improve it. > > Until then, at least the mailing list has a reasonable response rate and, > it seems, sufficient participation from knowledgeable folks willing to pitch > in and answer. So... if you're confused about something, please ask here. > > How about a search for the mailinglist archives? > >> One final comment, cmake is elegant in the extreme. I can see from some >> of the wiki pages about how install is a merge that canonically folds >> multiple precursors into one uber-powerful, uber-flexible silver bullet. >> Impressive I'm sure. But harder to grok. I'm not suggesting that this is >> a wrong choice. But it is a barrier to learning. Where there is this kind >> of folding of advanced features into basic operations, some care is needed >> to ensure the docs convey the basics clearly. >> >> WRT Cpack, what I find is that by merging it into CMake, the CPack code is >> declared one step away from where
Re: [CMake] CPack 101
On 23 December 2010 12:43, David Cole wrote: > Neither do we: > http://public.kitware.com/Bug/view.php?id=10067 > As always, as developers we find ourselves constantly working to improve > what we have: fixing bugs, implementing new features, answering questions on > the mailing list, blogging/communicating about it, adding examples and > suggestions to the Wiki. > > The struggle is reserving enough time to contribute to documentation when > there are always "real" (functional) bugs to be fixed. Perpetual questions: > what's "enough" documentation?, how do we make sure people can find it > easily?, how do we name this better (but still preserve the existing names > for people already using it / backwards compatibility)? > I make no excuses here: yes, the CPack and CTest documentation are lacking / > lagging behind the CMake documentation. However, it will take a very real > and concerted and time-consuming effort to improve the situation. With the > open source nature of the project, we have to be willing to accept the > organic growth that occurs in the code base: the documentation will be the > same: it will improve gradually, over time, as contributors are able to > improve it. I think the main problem is that you make it very hard for people to contribute. KDE and Homebrew (two other open-source projects I've written a lot of code for over the years) make this very easy. Kitware is great, you clearly write good code and have done a great job creating CMake and CPack. They are fantastic tools. However, I think until you are more encouraging of external developers you will struggle to make huge improvements to CMake. > Until then, at least the mailing list has a reasonable response rate and, it > seems, sufficient participation from knowledgeable folks willing to pitch in > and answer. So... if you're confused about something, please ask here. > We (I hope I speak for all CMake devs, here) take no offense. We welcome > discussion, always. The mailing list is OK but most people don't want to sign up to a mailing list and receive lots of emails that have nothing to do with them. I'm only signed up because I want to try and get some patches merged and was told that I should discuss things here rather than the bugtracker. I hope I don't cause any offense here either. I'm passionate about CMake because I like the tool and want to make it better. -- Mike McQuaid http://mikemcquaid.com ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On Wed, Dec 22, 2010 at 12:57 PM, KC Jones wrote: > Feeling really uneasy about putting this out there, but here goes... > > I have an app that I am building with cmake (2.8) on both Mac (10.6.40 and > Linux (Ubuntu 10.04). > The app depends on some libraries (Qt4.6 (no plugins) and a customized > build of Poco). > I want to generate a DragAndDrop DMG installer on Mac. (a la macdeployqt + > Poco lib packaging) > On Linux, I want a Debian package to install the Poco libs at a minimum > along with my executable. > Equivalent Windows installers will be needed someday. > > I've reviewed the docs at > http://www.cmake.org/cmake/help/cmake-2-8-docs.html > I've reviewed bits and pieces on the wiki: > http://www.cmake.org/Wiki/BundleUtilitiesExample > http://www.cmake.org/Wiki/CMake#CPack > > And I just don't seem to get it. I know this is very possible. I know this > is my own problem, first and foremost. So I'm exposing myself to potential > criticism here since RTFM and "get a clue" are probably the biggest part of > fixing my problem. Im not really asking for specific help on my code - I > might ask for that later. For now I just want to vent, hopefully in a > constructive way. > > I just don't think that CPack documentation and examples as they currently > are published are sufficient or effective. > > Neither do we: http://public.kitware.com/Bug/view.php?id=10067 A few suggestions: > >- More CPack example and tutorials would be very helpful. I see from >archive searches that I'm not the first to suggest this. The Qt example is >great, but the plugin support is overkill for most, and obfuscates much of >the rest of the example. >- A step-wise tutorial format that starts with a working build, adds >install target support, then adds CPack code would help my addled brain. > Presenting newbies like me with a fully baked end result is helpful, but >somewhat hard to digest. >- Separating the docs into different namespaces (Cmake, CPack, >CTest...) might be more effective. I struggled a long while before finding >the install command docs (which I continue to struggle with). The atomic >layout of the docs obscures the module-level relationships. >- A glossary, please. For instance "bundle" comes out of OS X, but now >has some CMake-specific meaning for Linux and Win that I know is very >important to me, but fully incomprehensible in my reading so far. Oh, and >what are bundle keys? >- More meta docs please. Somewhere in my stumbling I found a decent >diagram about how the ExternalProject module works. I think it was on the >wiki, but I can't find it now. I would die for something similar that > shows >what install does and how it integrates with CPack. Same goes for >BudleUtilities and other modules I've yet to discover. > > As always, as developers we find ourselves constantly working to improve what we have: fixing bugs, implementing new features, answering questions on the mailing list, blogging/communicating about it, adding examples and suggestions to the Wiki. The struggle is reserving enough time to contribute to documentation when there are always "real" (functional) bugs to be fixed. Perpetual questions: what's "enough" documentation?, how do we make sure people can find it easily?, how do we name this better (but still preserve the existing names for people already using it / backwards compatibility)? I make no excuses here: yes, the CPack and CTest documentation are lacking / lagging behind the CMake documentation. However, it will take a very real and concerted and time-consuming effort to improve the situation. With the open source nature of the project, we have to be willing to accept the organic growth that occurs in the code base: the documentation will be the same: it will improve gradually, over time, as contributors are able to improve it. Until then, at least the mailing list has a reasonable response rate and, it seems, sufficient participation from knowledgeable folks willing to pitch in and answer. So... if you're confused about something, please ask here. > One final comment, cmake is elegant in the extreme. I can see from some of > the wiki pages about how install is a merge that canonically folds multiple > precursors into one uber-powerful, uber-flexible silver bullet. Impressive > I'm sure. But harder to grok. I'm not suggesting that this is a wrong > choice. But it is a barrier to learning. Where there is this kind of > folding of advanced features into basic operations, some care is needed to > ensure the docs convey the basics clearly. > > WRT Cpack, what I find is that by merging it into CMake, the CPack code is > declared one step away from where it is applied. The need for careful > quoting in install(CODE ) blocks is a case in point. I'm sure this folding > into a canonical, unified single CMakeLists.txt source is a good thing. But > right now I feel like I'm learning
Re: [CMake] CPack 101
On 12/22/2010 11:24 PM, Andreas Mohr wrote:
> On Wed, Dec 22, 2010 at 04:15:07PM -0500, cmake-requ...@cmake.org wrote:
>> Date: Wed, 22 Dec 2010 09:57:11 -0800
>> From: KC Jones
>> Subject: [CMake] CPack 101
>
>> And I just don't seem to get it. I know this is very possible. I know this
>> is my own problem, first and foremost. So I'm exposing myself to potential
>> criticism here since RTFM and "get a clue" are probably the biggest part of
>> fixing my problem. Im not really asking for specific help on my code - I
>> might ask for that later. For now I just want to vent, hopefully in a
>> constructive way.
>
> I have nothing to add about your particular description, but let me just
> say that I can fully relate to how you feel, given that I hit a truly-WTF
> situation just yesterday, too:
>
> convert (imagemagick) appears to have incompatible versions which write
> to either file.xpm.0 or file-0.xpm (and there's no option to specify
> a specific file name prefix/format for icon series).
That is a bug in imagemagick then. Of course, you could do a
configure-check at CMake-time and figure out what naming scheme it uses
and then create your rules accordingly.
>
> So, to convert an icon file, add an add_custom_command().
> The problem then becomes how to know which file to choose
> for subsequent COMMAND lines,
> given that EITHER the one OR the other output file naming
> is available after conversion.
>
[SNIP long list of failures]
>
>
> That's 13 items of descriptions of failure (and I'm sure I forgot to
> list some other failed avenues which I had been thinking about).
>
> YUCK.
>
>
> I don't know what the perfect answer here is (or possibly I'm just blind
> for it?), but I know for certain that a simple Makefile rule
> would have a lot more flexibility / simplicity,
> and this simplicity is what CMake should strive to match
> while keeping its current very nice full generator/platform abstraction.
> Yes, of course that's hard, but IMHO the above story clearly shows that
> _something_ appears to be much too involved about it, since there was
> exactly no help at all anywhere, to defuse the situation to enable me
> to reach a satisfying result. IOW implementation pressure due to
> multiple CMake constraints is __MUCH__ too high, e.g. in the realms of line
> feeds / permissions / symlinks especially (multiple discussion threads on the
> internet about this).
>
You missed the obvious solution, as described above. Another solution is
that CMake is also a script-interpreter, and you can write arbitrary
scripts in the CMake language and then invoke them with ${CMAKE_COMMAND}
-P some_script.cmake in a custom command. In there you can do the full
thing: if(EXISTS ...), file(RENAME ...) etc.
Besides, simple Makefile rules won't help you on platforms without a
POSIX shell (e.g. Windows), so that would be even worse.
> To put it simply, I was just not happy the entire time while
> trying to implement this and not finding any satisfying (well-crafted)
> solution,
> only ugly, very bad or semi-failing workarounds.
> That kind of work should be _fun_, especially when it then results in a
> nicely working and fully automated result. It plain wasn't.
>
> I also recently witnessed a discussion (was it libusb?)
> where a suggestion for CMake build support was met with a clear number of
> replies tending away from it, likely due to similar experience. Unfortunately.
I'm not familiar with that particular discussion, but the usual FUD goes
along the lines that people don't want "yet another butt-ugly language".
Well, CMake language might not win a beauty contest, granted, but
ignoring the fact that the wide-spread autohell crap is a wild jumble of
POSIX-shell, Automake and, by far ugliest of all languages, M4. This
makes a total of 3 difficult to learn languages! So, replacing autohell
by CMake is actually a decrease by 2 languages, one of which must be the
most irritating and sadistic language ever invented (apart from
brainf*ck, that is).
>
> Hopefully my story will enable people to see where there are problems
> and how to approach any potential solutions.
>
> I have to say that so far I'm quite happy with the sufficiently large
> infrastructure that I was able to create, it's just that many areas
> feel wanting (the entire BundleUtilities / install-time stuff
> is an example of that, too).
I agree, the BundleUtilities need much more precise documentation.
>
> Thanks,
>
> Andreas Mohr
Michael
___
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://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake with Qt on Windows 7 MinGW
Hi there
I tried to use CMake for a small Qt project.
Here is my CMalkeLists.txt
[CODE]
# set project's name
PROJECT(TeXular)
cmake_minimum_required(VERSION 2.8)
SET(CMAKE_BUILD_TYPE Release)
# enable warnings
# ADD_DEFINITIONS( -c -g -Wall -frtti -fexceptions -mthreads
-enable-stdcall-fixup -Wl,-enable-auto-import
-Wl,-enable-runtime-pseudo-reloc)
SET(CMAKE_CXX_FLAGS "-Wall")
# this command finds Qt4 libraries and sets all required variables
# note that it's Qt4, not QT4 or qt4
FIND_PACKAGE( Qt4 REQUIRED )
# by default only QtCore and QtGui modules are enabled
# other modules must be enabled like this:
#SET( QT_USE_QTXML TRUE )
# add some useful macros and variables
# (QT_USE_FILE is a variable defined by FIND_PACKAGE( Qt4 ) that contains a
path to CMake script)
INCLUDE( ${QT_USE_FILE} )
# with SET() command you can change variables or define new ones
# here we define SAMPLE_SRCS variable that contains a list of all .cpp files
# note that we don't need \ at the end of line
SET( TEXULAR_SRCS
./src/main.cpp
./src/MainWindow.cpp
./src/TableModel.cpp
)
# another list, this time it includes all header files that should be
treated with moc
SET( TEXULAR_MOC_HDRS
./src/MainWindow.h
./src/TableModel.h
)
# some .ui files
SET( TEXULAR_UIS
./ui/MainWindow.ui
)
# and finally an resource file
# SET( TEXULAR_RCS ./src/rc/sample.qrc)
# and finally this will run moc:
QT4_WRAP_CPP( TEXULAR_MOC_SRCS ${TEXULAR_MOC_HDRS} )
# this will run uic on .ui files:
QT4_WRAP_UI( TEXULAR_UI_HDRS ${TEXULAR_UIS} )
# this command will generate rules that will run rcc on all files from
TEXULAR_RCS
# in result TEXULAR_RC_SRCS variable will contain paths to files produced by
rcc
#QT4_ADD_RESOURCES( TEXULAR_RC_SRCS ${TEXULAR_RCS} )
# we need this to be able to include headers produced by uic in our code
# (CMAKE_BINARY_DIR holds a path to the build directory, while
INCLUDE_DIRECTORIES() works just like INCLUDEPATH from qmake)
INCLUDE_DIRECTORIES( ${CMAKE_BINARY_DIR} )
# here we instruct CMake to build TEXULARexecutable from all of the source
files
ADD_EXECUTABLE( texular ${TEXULAR_SRCS} ${TEXULAR_MOC_SRCS}
${TEXULAR_RC_SRCS} ${TEXULAR_UI_HDRS} )
# last thing we have to do is to tell CMake what libraries our executable
needs,
# luckily FIND_PACKAGE prepared QT_LIBRARIES variable for us:
TARGET_LINK_LIBRARIES( texular ${QT_LIBRARIES} )
INSTALL_TARGETS( /bin texular)
[/CODE]
Then I run:
[CODE]
cmake -G"MinGW Makefiles"
mingw32-make.exe
[/CODE]
Everything builds without error.
But if I launch my application I get an error :
The procedure entry point _Z17qt_message_output9QtMsgTypePKc could not be
located in the dynamic link library QtCore4.dll
If a check the binary with Dependency Walker and compare with an other
binary (created with a qmake makefile) I see that there is Mingw10.dll
missing.
How do I tell cmake to link against Mingw10.dll?
Or is the procedure entry point error not because of missing Mingw10.dll?
Platform is Win7 64 bit. Qt Version 4.7
Thanks for your help.
Cheers LukeS
___
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 22 December 2010 22:24, Andreas Mohr wrote: > To put it simply, I was just not happy the entire time while > trying to implement this and not finding any satisfying (well-crafted) > solution, > only ugly, very bad or semi-failing workarounds. > That kind of work should be _fun_, especially when it then results in a > nicely working and fully automated result. It plain wasn't. It's hard to understand exactly what your problems are other than just learning CMake. I suggest you make a new thread and try and explain these clearly, it's pretty hard to try and help from your previous descriptions. > I have to say that so far I'm quite happy with the sufficiently large > infrastructure that I was able to create, it's just that many areas > feel wanting (the entire BundleUtilities / install-time stuff > is an example of that, too). I agree. I think the install-time/CPack/dependency stuff needs some work. -- Mike McQuaid http://mikemcquaid.com ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
To start with, Charm might be a good example of how to use CPack, it's an internal tool we've written in Qt and use CPack to do all the packaging: https://github.com/KDAB/Charm Check particularly the CMakeLists.txt and Charm/CMakeLists.txt for all the CPack-relevant logic. On 22 December 2010 17:57, KC Jones wrote: > I just don't think that CPack documentation and examples as they currently > are published are sufficient or effective. I completely agree. > More CPack example and tutorials would be very helpful. I see from archive > searches that I'm not the first to suggest this. The Qt example is great, > but the plugin support is overkill for most, and obfuscates much of the rest > of the example. > A step-wise tutorial format that starts with a working build, adds install > target support, then adds CPack code would help my addled brain. Presenting > newbies like me with a fully baked end result is helpful, but somewhat hard > to digest. Agreed. > A glossary, please. For instance "bundle" comes out of OS X, but now has > some CMake-specific meaning for Linux and Win that I know is very important > to me, but fully incomprehensible in my reading so far. Oh, and what are > bundle keys? BundleUtilities is a really bad name. As I've said before, the naming stops Windows and Linux people from finding this functionality until they post on the mailing list or bugtracker. It's worth remembering that 90% (if not more) people won't even get here and will just use another tool. BundleUtilities/GetPrerequisites should really be rolled into CPack, I'd be pretty amazed if many people were using it outside of CPack. > More meta docs please. Somewhere in my stumbling I found a decent diagram > about how the ExternalProject module works. I think it was on the wiki, but > I can't find it now. I would die for something similar that shows what > install does and how it integrates with CPack. Same goes for BudleUtilities > and other modules I've yet to discover. Really what's needed is less API documentation and more workflow documentation, perhaps based around user stories. If I just want to set up a CMake project and build a package there should be a step-by-step walk through the documentation. > One final comment, cmake is elegant in the extreme. I can see from some of > the wiki pages about how install is a merge that canonically folds multiple > precursors into one uber-powerful, uber-flexible silver bullet. Impressive > I'm sure. But harder to grok. I'm not suggesting that this is a wrong > choice. But it is a barrier to learning. Where there is this kind of > folding of advanced features into basic operations, some care is needed to > ensure the docs convey the basics clearly. Agreed. > WRT Cpack, what I find is that by merging it into CMake, the CPack code is > declared one step away from where it is applied. The need for careful > quoting in install(CODE ) blocks is a case in point. I'm sure this folding > into a canonical, unified single CMakeLists.txt source is a good thing. But > right now I feel like I'm learning Lisp again. Kind of mind blowing. > Wishing I had some better training wheels to break this down for me... > Thanks for your indulgence. I hope this does not offend those who've put so > much into this great tool. I think integrating CPack into CMake is good but it hasn't been done very well. INSTALL(CODE) is just a mess and it would be good to be able to interact with CPack for typical usecases (e.g. use BundleUtilities to install all dependencies of an executable only at package time) and roll this into normal CPack syntax. I think the biggest problem is that people complain about CPack not being easy to use and are simply told how to do the task they've had the problem with and the bug/mail is ignored. The problem isn't the CPack functionality, it's accessing it and the lack of discoverability of it's features. I want to try and help and write patches for this stuff but I create bugs and they are ignored and then post on the mailing list and no-one from Kitware comments. I really appreciate that everyone is very busy but it feels like the CPack developers think it's good enough as-is and aren't particularly interested in attracted new contributions and improving the project. -- Mike McQuaid http://mikemcquaid.com ___ 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack 101
On 22.12.10 23:24:35, Andreas Mohr wrote: > - there's no cmake -E rename available (perhaps for reasons of build rule > atomicity) Hmm my cmake -E help tells me different: ... rename oldname newname- rename a file or directory (on one volume) ... This is cmake version 2.8.2.20100804-ga42a4 Andreas -- You will be singled out for promotion in your work. ___ 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://www.cmake.org/mailman/listinfo/cmake
