[CMake] Question about distribution questions

[Dizzy]

On Friday 21 September 2007 14:55:43 Joachim Ziegler wrote:
> Hello Eric,

I'll drop in and try to answer the questions.

> >   2 -  installing your project (i.e. no error when calling 'make
> > install')
>
> This does not. I have no target "install". Browsing through
>
> http://www.cmake.org/HTML/WritingCMakeLists.html
> http://www.cmake.org/HTML/Examples.html
>
> I discover nothing about how to create this target. I suppose (sorry for
> my stupidity) it has something to do with the INSTALL command mentioned on
>
> http://www.cmake.org/HTML/Documentation.html
>
> I have already played a bit with this, by means of trial and error, but
> frankly speaking, I do not understand the documentation of INSTALL or
> INSTALL_FILES (moreover, I do not want anything to be installed, I just
> want to have a.h, a.cpp, b.h, b.cpp, main.cpp compiled and packaged for
> delivery). Maybe I understand something completely wrong here.

Yes, as long as you don't have at least one INSTALL() command there is no 
install target. It will show up the moment you start to add installation 
rules.

So you said you want some package made of some files, but a package means some 
files that eventually will be on the system in some locations (when the 
package is installed) so with cmake INSTALL() commands you specify how are 
those files to be installed (if the user would run a hypotethical "make 
install") and CPack will use that information to create the package ("CPack" 
has to know in what locations what files do you have, those are automatically 
determined based on the installation rules created with INSTALL).

>
> > The customer should do:
> >
> > 1 - unpack i.e. tar zxvf <packagename>.tar.gz
> >      which creates
> > 2 - create a build tree
> >      run cmake
>
> So the customer MUST have cmake installed!?

Yes if you are giving him a source release. CMake is not replacing 
autoheader/autoconf/automake but is replacing those AND "configure" (there is 
no intermediate "configure" script created by running cmake that may be run 
by a compatible shell). Since CMakeLists.txt files are written (normally) 
using only CMake commands it means that as long as you have a cmake on that 
platform then those commands will do what you want (which is much more 
portable than autotools that need a compatible shell and paths, especially on 
non-UNIX platforms with CMake it's easier).

> > We did add a paragraph on this in our TSP Programming Tutorial:
> > http://download.savannah.nongnu.org/releases/tsp/documentations/tsp_progr
> >amming_tutorial-1.0.pdf
>
> Nice document. And you write at the very beginning:
>
> "1. Check you have the CMake installed (see A.1)."
>
> OK, this answers my question! (Chances are high that my customer will
> not accept this, but that's his problem :-) )

In that case you cannot give your customer a cmake based source release (as 
people said here, cmake is required even after generating of makefiles 
because they are not purely native so you cannot run cmake to generate 
makefiles on a system similar to the user and give them the result to just 
run the native "make").

I don't understand tho why it is then acceptable to run configure, you assume 
that your client has a compatible shell in that case (which is not generally 
true, especially for non UNIX systems).

-- 
Mihai RUSU					Email: dizzy at roedu.net
			"Linux is obsolete" -- AST