[Cmake] What I don't understand about CMake

Stefano Barbato barbato at inquare . com
Fri, 14 Nov 2003 13:53:29 +0100


I think that CMake have different kind of user base based on OS type.

When looking from Windows prospective CMake could be considered a developer 
tool since Windows *users* are not used to and don't usually benefit (or 
care) about building from source code. CMake handes compilation and packaging 
of binary files on developers machine, and those binary files will be 
distributed to end-users. If somebody wants to compile by himself then he 
must install CMake.

Looking from Unix side CMake must be an end-user tool since most of the time 
users need to buid from source because Unix environments could be very 
different one another. Binary distribution is often not feasible. So here 
we're shifting our target user from the developer to the end-user.

So here is the today-madness-question :) Wouldn't a CMake-to-autotools 
convertion feature fix this gap by allowing developers to take advantage of 
CMake power features and end-users to compile without downloadind and 
installing anything more then the application they want to use?

This probably will not help to spread cmake on all unix systems around but 
will help spreading cmake on developers PCs.

stefano

On Wednesday 12 November 2003 19:24, you wrote:
> We have given this a lot of thought.   I think you could come up with
> a solution that worked some of the time for some projects.  But for a
> general solution it is not really possible.  Generating makefiles and
> distributing them will only work for small projects that do not depend on
> much.
>
> The problem is that autoconf really depends on a big list of executables
> that happen to be on most unix systems, but not on windows.   So, you have
> to get that functionality from somewhere. The plan is to have cmake be as
> available as say gnu-make is.  However, it really is a chicken and the egg
> problem.
>
> I also do not agree with the argument that Windows does not need
> configuring. Again, small projects may not, but then those projects maybe
> should just have hard coded makefiles anyway.  As soon as you try and
> find/use external software it is always installed in random places.
>
> One idea we have thought about, is to create a minimum-cmake that can be
> incorporated into a project.  It would be built during the configure step
> and then run on the project.
>
>
> -Bill
>
> At 11:53 AM 11/12/2003, Stefano Barbato wrote:
> >Bill, thanks for your reply.
> >
> >I understand what you wrote but we all know that it's very difficult to
> > force users to download and install something new and, even worse,
> > something of which they probably don't even understand the usefullness
> > and expecially if the build environment is much bigger then the package
> > itself.
> >
> >So knowing that many multi-platform apps/libraries used the
> > multi-makefiles method of building on different machines (see vim, zlib
> > and many others) I think would be great to use CMake to generate such
> > makefiles. Having CMake would be better but generating makefiles should
> > be an option I think.
> >
> >Pre-generated makefiles would probably work without change on Windows
> >paltforms where is more difficult to find substantial differences.  On
> > more difficult platforms a small program able to set simple run-time
> > variables (i.e. make variables)  based on the end-user machine could be
> > enough to successfully 'make all' without running CMake.  Do we really
> > need the whole CMake to find end-user paths? Couldn't a autogenerated C++
> > program find all interesting paths and set variables or modify a Makefile
> > or create a sort of config.make with all paths to include in the other
> > Makefiles?
> >
> >My developer dream would be a system that let you create project files
> > with few lines of text, as CMake does, and generates a set of files that
> > included into the my software's distribution package would handle
> > compiling automatically without any external requirement. Oh well, I mean
> > without including the CMake sources into my tar.gz :)
> >
> >
> >stefano
> >
> >On Wednesday 12 November 2003 16:27, William A. Hoffman wrote:
> >> CMake IS required to be installed by the end users.
> >>
> >> Here is the explaination. The only tool that is really shared across all
> >> platforms is the c/c++ compiler.  The build system can not depend on
> >> "common" tools because there are none.  A typical configure script
> >> depends on: sh, sed, echo, /dev/null, test, chmod, hostname, and cat. 
> >> In short, a fairly complete UNIX environment.  So, CMake depends on the
> >> one common tool, the c/c++ compiler.   It was felt that for a c/c++
> >> project this would not be too much to ask. The union of available shell
> >> functions is very small across windows and UNIX.  CMake is in a sense a
> >> small portable shell.
> >>
> >> It really comes down two this.  With autoconf, windows users must
> >> install a UNIX compatibility layer like cygwin or mingw, and they can
> >> not use IDE build tools, but must use command line make.   With CMake,
> >> both windows and UNIX users have to install one program CMake, and after
> >> running cmake can use the system build tools.
> >>
> >> It really would not work very well to generate makefiles and move them
> >> to a different machine.   CMake finds all the paths for a particular
> >> machine. And if all machines were the same, we would not need cmake or
> >> autotools.
> >>
> >> One solution, might be to include some sub-set of cmake sources inside a
> >> project, and build it.   However, many projects depend on gnu make and
> >> do not include the source or build gnu make for each project.  They just
> >> expect users to download and install gnu make first.
> >>
> >>
> >> -Bill
> >>
> >> At 10:06 AM 11/12/2003, Stefano Barbato wrote:
> >> >I read CMake documentation and examples but there's something I don't
> >> >understand about CMake.
> >> >
> >> >I think that what's good about autotools is that the build environment
> >> > can be shipped with the source package because of its small size but
> >> > CMake is big to distribute with all packages.
> >> >
> >> >So I thought that CMake had to be installed on developers machines and
> >> > that with a single command it could generate *all* supported
> >> > platform-native makefiles or project files that would be included into
> >> > distribution packages. Probably a small auto-compiling program able to
> >> > choose between generated makefiles/prjfiles (based on on-site tests)
> >> > could be easily included into the distribution source archive (I used
> >> > this approch when coding my simple unit testing engine where the
> >> > engine core is distributed as source file and auto-compiled on
> >> > end-user machine before anything else).
> >> >
> >> >But my CMake installation seems to be able to generate only my platform
> >> >Makefiles.
> >> >
> >> >So must CMake be installed on destination end-user PCs for them to be
> >> > able to compile? can CMake generate all supported makefiles and
> >> > project files at once? Does this message make any sense? :)
> >> >
> >> >Thanks.
> >> >
> >> >Stefano Barbato
> >> >
> >> >_______________________________________________
> >> >Cmake mailing list
> >> >Cmake at www . cmake . org
> >> >http://www . cmake . org/mailman/listinfo/cmake
> >>
> >> _______________________________________________
> >> Cmake mailing list
> >> Cmake at www . cmake . org
> >> http://www . cmake . org/mailman/listinfo/cmake
> >
> >_______________________________________________
> >Cmake mailing list
> >Cmake at www . cmake . org
> >http://www . cmake . org/mailman/listinfo/cmake