> If you do cmake -f client.txt, then every add_subdirectory and subdirs
> will now look for client.txt. That is not the way make -f works. If
> you do make -f it just changes the initial makefile that is read into
> make, after that it is up to the makefile writer to use include, or
> recursive make to specify additional makefiles that are included. And,
> cmake -f client.txt would not be the same thing as make -f client.mk, as
> make -f client.mk would actually do a build. For the cmake, one you
> would have cmake -f client.txt, make (with no -f). I am still not
> convinced this is a good idea.
> -Bill
That might work too.
I also does not understand why You are soo resistant to a minor feature which
couldn't really hurt anyone?
Actually i could do with if just CMake also accepted "CMakeLists.cbs" as
makefiles, since that's what I intended to use for the project I mentioned.
With my project you would be able to easily use common SW librairies in you
project. I am simply trying to make it much much easier for people to write
cross platform C++ code reusing existing libraries and ofcourse cmake. To
that end I could really use just a tiny bit of help from the cmake-team.
I am still a least one half year from releasing something, but I can try to
explain the basic idea.
Simple example from my actual codebase. CBS (Common Build System) makefiles
for zlib and libpng, which depends on zlib (install stuff not included):
--- z.cbs ---
TARGET_DEFAULT_VERSION ( 1 2 3 )
ADD_SOURCE_FILE ( adler32.c )
ADD_SOURCE_FILE ( compress.c )
...
ADD_SOURCE_FILE ( inffast.c )
--- png.cbs ---
TARGET_DEFAULT_VERSION ( 1 2 16 )
ADD_DEPENDS_ON ( z )
ADD_SOURCE_FILE ( png.c )
ADD_SOURCE_FILE ( pngerror.c )
...
ADD_SOURCE_FILE ( pngwutil.c )
--------------------------------
Note the ADD_DEPENDS_ON ( z ) for png. This single line takes care of all
needed includes, linkdirs/libraries etc. thats neeeded to compile and link
libpng. For additional include use ADD_INCLUDE_DIR.
In the (in time hopefully rare) cases where you depend on external libraries
you use ADD_LINK_DIR, ADD_LINK_LIBRARY
In case you need to add defines you can do
ADD_DEFINE or ADD_PUBLIC_DEFINE
I even made an ADD_SOURCE_FILE_QT which adds a C++ file for normal compilation
and if there's and associated header call the moc compiler on that and adds
the generated source file to the list of sources. Have also easy handling of
flex,bison and in the cbs-files for Mozilla also support for their IDL files
using the IDL compiler built in same pass using CBS/CMake.
There are currently a cbmake.py script which simplifies the generation of
makefiles for out of source build for all targets. Simply write:
'cbmake.py -g kdev -b debug -l static' (debug in KDevelop. Libs static )
OR
'cbmake.py -g vc8 -l shared' (Create VC8 files all libs default DLL's)
Also shellscripts/bat files for the most common uses so you at least in
Windows never need to see the command line: Just doubleclick a bat file and
go open you project in Visual Studio.
About the command line script I do plan for it to also have a GUI at some
point similar to VisualStudios Solution Explorer, where you can set your
build options add files etc. To make a GUI tool as easy as possible to create
I strive to keep the source makefiles really simple like lines of ADD_XX ()
so parsing and manipulating them from a GUI tool can be done.
--- Main configuration file ---
Lastly I should mention some of the cool stuff you can do in the main
configuration file, by this example from (again from my actual codebase):
SET ( z_USE SYSTEM ) # Use system version (currently not Windows)
SET ( png_USE BUILD ) # Build from sources in this project
SET ( bz2_USE PREBUILT ) # Prebuilt (with CBS) from othter source tree.
SET ( z_LINK_TYPE STATIC ) # Build/use zlib static event though current
default for project as a whole is to make shared libs/DLLs.
As you can see it's possible to intermix the usage of shared/static, own built
with a system installed library etc. all from one central place.
One hassle for instance getting gcc to use and link with a static version of a
system installed library like z(lib) in the example configuratiob file is
also solved since I simply copy static librairies from system dirs to own
link dir and directs the linker to look there first - This way gcc is forced
to use the static version since the shared one is not present in the same
dir.
Well hope that gave you an impression of what it is. So the reason I need an
anternative name for the CMakeLists.txt file is that I wan't CBS makefiles to
be able to live side by side with a projects own CMake files. So far the only
project I am considering creating CBS files for, which allready uses CMake is
KDE, but that might change and I would like allready now to be able to rename
my files in preparation and also because I might try and convert KDE in the
not too far future.
-Regards Martin Lutken
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
