Hi Karl!
I'm currently (as a consultant) converting ~2.5 Mio LOC C++/C from
vcproj/Makefiles/qmake to cmake.
Can you say something of the motivations for your client to do this?
I suspect that you are expected to keep most of their development
workflow and processes in order. Which parts are you allowed to redesign
and which have to stay?
For us, there are also strong non-technical factors that will affect the
decision to improve the build system, such as:
1) Is there some migration path from the old system?
2) Can we get around taking two weeks off where everybody needs to learn
a new tool?
3) Can we keep the knowledge that went into the scripts, makefiles and
qmake-projects of the current system?
4) Does it offer enough advantages to take the risk to change a matured
and operative build system (albeit the latter is running at its limits)?
There are more points, but I'll need to address them all in order to
convince anyone to even try cmake.
Right now, my plan is to convert a substantial part of the project to
cmake. It needs to work with all our code generators. It will include a
subproject that has a substantial amount of unit, integration and
regression test that all need to be passed afterwards. And the migration
path could be to just check in the CMakeLists.txt into the repository
and be grateful that cmake builds out of source.
Part of my non-technical review will be the amount of time and pain it
took me to do the conversion. The book (Mastering CMake) and the
superfriendly and professional mailing lists will surely be big selling
points there :-)
I'd be really interesting to know what non-technical issues you are
facing with your current project!
- Automate everything (You need: continuous build and delivery, use
cdash or hudson)
- Complete build process (You need: checkout, build, packaging and install)
We do that with bash scripts and virtual machines.
Which is why running cmake must be fully scriptable.
I understand that it is if you are passing it the required configuration
parameters with cmake -DTHIS_AND_THAT.
There are others ways to build faster, like ccache
(http://ccache.samba.org/) or distcc (http://distcc.samba.org/).
We are using both for regular developer builds in linux. With release
builds, we are a little more reluctant and expect everything to build in
bearable time from scratch on a single machine. This works, just short
of the bearable part.
If you are going to change tools (introduce cmake), it is also time to
review your development process (If in the business world e.g. a
SAP-Systems is introduced the complete work flow and business processes
will get adapted).
I'll collect all the suggestions from this list and summarize them in a
report.
Thanks a lot for being so helpful, that's much appreciated!
Cheers,
Benjamin
_______________________________________________
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
