[Cmake] out of source builds

[Doug Henry]

sorry, my wording may have been incorrect.  I am doing an out of source
build.  The in source build works perfectly.  I have a source tree (I
call it main) and then I have two dirs called b32 and b64.  I do a cmake
../source -D:NBITS=32 and then make.  There is nothing in the b32 or b64
dirs when I start.  I believe this process is exactly the same as the
debug and release some people have been talking about, I am just
applying the same concept to build 32 and 64 bit versions of my software
in their own trees.  The main problem seems to be that when I am
building in my b32 directory, current_dir/gentypes points to the source
tree even though it built gentypes in the correct location under b32.

On Wed, 2004-01-07 at 09:07, Karr, David wrote:
> > I am trying to use the out of source build capability.
> > I have a main source tree and then a few others with
> > different build options.
> 
> By "source tree," do you mean the directory where you 
> keep the actual source?  By definition, if I understand 
> the CMake terminology, there can be only one source tree 
> (so "main" is redundant) unless you are maintaining 
> multiple versions of the source with different lines of 
> code, and an  out-of-source build will not put any 
> binary files in the source tree.
> 
> I am guessing that you actually do an in-source build 
> (putting binary files in the same directory tree where 
> the source is) and the you do some out-of-source builds 
> elsewhere.  I have a related issue, I like to do 
> out-of-source builds all the time but must of the 
> developers on my team seem to do in-source builds, so 
> I've taken care to make sure both ways work for the 
> same source and CMake files.
> 
> > gentypes is built correctly, but when it tries to
> > create the header, it tries running gentypes from
> > the main source tree and not from
> > the current source folder.  Is this a bug?
> 
> > ADD_CUSTOM_COMMAND (
> > 	OUTPUT ${CMAKE_HOME_DIRECTORY}/libcommon/include/Types.h
> > 	DEPENDS gentypes
> > 	COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/gentypes
> > 	ARGS ${CMAKE_HOME_DIRECTORY}/libcommon/include/Types.h
> > ${CMAKE_HOME_DIRECTORY}/data/types.xml
> > )
> 
> It seems this is doing what it is told to do.
> CMAKE_CURRENT_SOURCE_DIR is a directory in your source
> tree ... the *source* tree where the original source
> files all are, *not* the tree where you perform your
> out-of-source build.  This is why I inferred you must be
> performing an in-source build before you perform any of
> your out-of-source builds, because only the in-source
> build would put the binary file "gentypes" in your
> source tree; if you hadn't done this, you wouldn't just
> get the "wrong" copy of gentypes, you wouldn't find it
> at all.
> 
> To denote the corresponding directory in your 
> out-of-source build tree, I believe you should write
> CMAKE_CURRENT_BINARY_DIR, that is, it's "SOURCE" when it 
> is the unique directory tree where all the source files 
> live, and "BINARY" when it is wherever you are building 
> the binaries.
> 
> What interests me is I was just thinking this morning 
> that I might want to add some generated source code to
> my current project, and I wonder: shouldn't the generated
> code go into the "binary" tree?  I imagine this might
> raise some issues about how the workspace or makefile
> would find the generated code, since a more "conventional"
> (strictly in-source) build procedure would typically end
> up with the generated "source" in the same directory as
> a bunch of human-written source files.
> 
> David
> 
> _______________________________________________
> Cmake mailing list
> Cmake at www.cmake.org
> http://www.cmake.org/mailman/listinfo/cmake