CMake

[Andrew]

It would be nice if you could consider using Cmake as your cross-platform build system. By using CMake you can automate building and installing across all platforms. Even KDE is now using CMake. Another plus with CMake is that it knows about IDEs and will generate the required files for them. Check it out at www.cmake.org.


It is the best solution that we have found for cross-platform work. We develop in Linux, Windows XP and QNX.


Andrew

[marlowa]

> It would be nice if you could consider using Cmake as your cross-platform build system. By using CMake you can automate building and installing across all platforms. Even KDE is now using CMake. Another plus with CMake is that it knows about IDEs and will generate the required files for them. Check it out at www.cmake.org.
>
> It is the best solution that we have found for cross-platform work. We develop in Linux, Windows XP and QNX.

I am not familiar with CMake but based on the quick look I took, I am not keen. I think Poco makes very good use of make, including handling the dependency mgmt issue. What I mean by that is that Make-based build solutions need to cope with the fact that Make does not do a dependency analysis of the source to figure out what to rebuild. It relies on the dependencies to be stated in the Makefile. This is one of the biggest problems I have with Make and tools that are based upon it. I have seen a few systems take this problem head on and win, but not many. Poco is one of the successful ones. Congrats to Poco because IMO this is a tricky thing to get right.

I cannot find whereabouts in the CMake documentation the issue of how dependencies are handled. Once the build takes dependencies into account, parallel builds become possible. I could not see that in the documentation either. Because Poco handles dependencies and allows GNU Make to be used, the -j option can be used for parallel builds, which tends to speed things up dramatically on multi-CPU machines.

Perforce jam also handles dependency mgmt and enables parallel builds but the language used for the build rules is involved and things get quite complicated for non-trivial projects. But IMO this is the best tool available when Make is not being used.

CMake reminds me of imake; lots of macros that have to be learnt in order to be able to use the tool. The advantage of Make is that its rules, syntax etc are well-known and do not have to be learnt (I am assuming that most developers have some familiarity with development in a unix environment). IMO imake failed because only experts could drive it. Only the experts had commited the myriad of macros to memory so they could call upon the right ones for succinct (i)makefiles. It looks to me like CMake would have the same problem.

An alternative that people might want to take a look at is Make Project Creator, MPC. This is also a tool based on generating native Makefiles, project files, etc, but it does not rely on macro names. It has its own syntax which IMO is much easier than jam. MPC is currently distributed with the ACE project.

-Andrew Marlow

[Andrew]

CMake does have a steep learning curve at first. It is important to but yhe book. But support is really great throug the user group and wiki. I guess like all things you have to try it and see if it works for you.

However once your library has been converted it it very simple for users to compile/build/use the library as configuration files can be automatically generated. You also don have to wioorry so much about sross-platform peculiarities and IDE issues. So we often just have a Find.cmake file that users simply include in their CMake file - it sets all the include libraries etc. and can even be used to set specific compiler settings.

CMake does handle dependencies automatically and also allows the -j option if using make. You generally don't have to specify dependencies at all. It also provides a large number of try compile anf other find modules so that system inspection is reasonablly complete.

So because we run three platforms XP (where people prefer to use IDEs most have never heard of make or nmake!), Linux (some use KDevelop3) and QNX make/Eclipse, we have had to move to CMake. We llooked at jam/bjam and the others you mention but CMake provided the best features. It is also provides the ability to do unit testing automatically. You can see this on http://www.cmake.org/Testing/Dashboard/20060921-0100-Nightly/Dashboard.html where nightly builds of it on various platforms are done.

So we like CMake bacause of:
1) It is cross-platform.
2) Supports IDEs.
3) Automates testing.
4) It is under active development and fixes are usually pretty quickly applied.
5) Quality control exists as can be seen from the dashboard.

I was also particularly interested to see that it is now used for KDE - there is a huge project with a mixed C/C++ code base and multiple dependency issues. In fact Kitware created a special version of CMake for it and subsequently merged the enhancements into the main tree. So we have all benefited from the lessons learned here.

So if you are serious about cross-platdorm support it is worth a look.

By the way I think CMake evolved from something called PCMake.

Andrew

[pierre.souchay]

> It would be nice if you could consider using Cmake as your cross-platform build system. By using CMake you can automate building and installing across all platforms. Even KDE is now using CMake. Another plus with CMake is that it knows about IDEs and will generate the required files for them. Check it out at www.cmake.org.
>
>
> It is the best solution that we have found for cross-platform work. We develop in Linux, Windows XP and QNX.

I agree with him, cmake is quite elegant and easy.I take the opportunity to add my detection script for POCO and CMake integration:

!FindPoco.cmake

Code: Select all


SET(POCO_DIR "poco")
FIND_PATH(POCO_INCLUDE_DIR Poco/Poco.h PATHS ${POCO_DIR}/include /usr/local/include /usr/include ENV INCLUDE DOC "POCO include directory")

FIND_LIBRARY(POCO_LIBRARY NAMES PocoFoundation PocoFoundationd PATHS ${POCO_DIR}/lib /usr/local/lib /usr/lib ${POCO_INCLUDE_DIR}/../lib ENV LIB)
FIND_LIBRARY(POCO_LIBRARYD NAMES PocoFoundationd PocoFoundation PATHS ${POCO_DIR}/lib /usr/local/lib /usr/lib ${POCO_INCLUDE_DIR}/../lib ENV LIB )

FIND_LIBRARY(POCO_NET_LIBRARY NAMES PocoNet PocoNetd PATHS ${POCO_DIR}/lib /usr/local/lib /usr/lib ${POCO_INCLUDE_DIR}/../lib ENV LIB )
FIND_LIBRARY(POCO_NET_LIBRARYD NAMES PocoNetd PocoNet PATHS ${POCO_DIR}/lib /usr/local/lib /usr/lib ${POCO_INCLUDE_DIR}/../lib ENV LIB )

FIND_LIBRARY(POCO_UTIL_LIBRARY NAMES PocoUtil PocoUtild PATHS ${POCO_DIR}/lib /usr/local/lib /usr/lib ${POCO_INCLUDE_DIR}/../lib ENV LIB )
FIND_LIBRARY(POCO_UTIL_LIBRARYD NAMES PocoUtild PocoUtil PATHS ${POCO_DIR}/lib /usr/local/lib /usr/lib ${POCO_INCLUDE_DIR}/../lib ENV LIB )

FIND_LIBRARY(POCO_XML_LIBRARY NAMES PocoXML PocoXMLd PATHS ${POCO_DIR}/lib /usr/local/lib /usr/lib ${POCO_INCLUDE_DIR}/../lib ENV LIB )
FIND_LIBRARY(POCO_XML_LIBRARYD NAMES PocoXMLd PocoXML PATHS ${POCO_DIR}/lib /usr/local/lib /usr/lib ${POCO_INCLUDE_DIR}/../lib ENV LIB )

IF (POCO_INCLUDE_DIR AND POCO_LIBRARY)
   SET(POCO_FOUND TRUE)
ENDIF (POCO_INCLUDE_DIR AND POCO_LIBRARY)


To use it, simply add the following directives then in your 'CMakeList.txt'

Code: Select all


LIST(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/modules)
FIND_PACKAGE(Poco REQUIRED)
INCLUDE_DIRECTORIES ( ${POCO_INCLUDE_DIR} )


Where modules would be a directory where you have put the 'FindPoco.cmake' file, and for instance, to link your amazing application:

Code: Select all


TARGET_LINK_LIBRARIES ( MY_APPLICATION
   optimized ${POCO_LIBRARY}
   debug ${POCO_LIBRARYD}
   optimized ${POCO_NET_LIBRARY}
   debug ${POCO_NET_LIBRARYD}
   optimized ${POCO_UTIL_LIBRARY}
   debug ${POCO_UTIL_LIBRARYD})


I use this for my compilations and was tested successfully under Linux, Solaris, MacOS and Win32 (under WIN32, just set POCO_DIR to the path where you installed poco before launching CMake Wizard).

Pierre

>
>
> Andrew

[alex]

> I agree with him, cmake is quite elegant and easy.I take the opportunity to add my detection script for POCO and CMake integration:

Pierre,

The official POCO policy is that we stick with build systems that are present by default on the target systems (i.e. gmake for POSIX and VS for Win32). The rationale behind this policy is that anything else but a build system present by default puts additional burden on the user and acts as a detractor for potential newcomers to Poco.

As for CMake, we welcome all contributions and Andrew has already contributed some scripts that are part of distribution. They can be found under $POCO_BASE/contrib/cmake. If you can improve those, please feel free to do so. Your contribution will certainly be welcome.

Alex