[Cmake] [PATCH] Custom LIB/EXE output path for each CMakeList.txt
Nitin Gupta
ngupta at GlobespanVirata . com
Fri, 18 Jul 2003 17:28:43 +0530
Hi Bill,
The solution does not seems to work for
Linux builds, mainly when an executable in
higher CMakeLists.txt *depends* upon the
library in one of SUBDIRs. In this case
the Makefile of higher directory (executable)
assumes the SUBDIR library in the path
defined by its LIBRARY_OUTPUT_PATH whereas
the Makefile of SUBDIR library contains the rules
that assumes the library to be generated in
directory defined by its LIBRARY_OUTOUT_PATH.
The "make" would break when building DEPEND_LIBs
of executable.
Consider:
PROJECT(foo)
SET(FOO_EXE_PATH "foo_exe" CACHE...)
SET(FOO_EXE_PATH "foo_lib" CACHE...)
SET(EXECUTABLE_OUTPUT_PATH ${FOO_EXE_PATH})
SET(LIBRARY_OUTPUT_PATH ${FOO_LIB_PATH})
SUBDIR(BAR1 BAR2)
ADD_EXECUTABLE(foo ...)
ADD_DEPENDENCIES(foo bar1 bar2)
---BAR1---
PROJECT(BAR1)
SET(BAR1_LIB_PATH "bar1_lib" CACHE...)
SET(EXECUTABLE_OUTPUT_PATH ${BAR_EXE_PATH})
ADD_LIBRARY(bar1 ...)
---BAR2---
PROJECT(BAR2)
SET(BAR2_LIB_PATH "bar2_lib" CACHE...)
SET(EXECUTABLE_OUTPUT_PATH ${BAR_EXE_PATH})
ADD_LIBRARY(bar2 ...)
Now the makefile of FOO would contain
foo_DEPEND_LIBS = ... lib/libbar1.a lib/libbar2.a
...
lib/libbar1.a :...
cd BAR1;..; make lib/libbar1.a
Whereas the Makefile in BAR1 would contain target
bar1_lib/libbar1.a instead.
Hence a "make" for FOO would break complaining
**No rule to make target lib/libbar1.a
>
> There is no need for a patch. This can already be done from the
> CMakeLists.txt files
> with a SET command. A common technique for overriding global
> cache variables is
> to create a project specific variable, and then to use SET to
> override the global
> one in the local directory.
>
>
> So, the following is an example:
>
> PROJECT(foo)
> SET(FOO_EXE_PATH CACHE...)
> SET(EXECUTABLE_OUTPUT_PATH ${FOO_EXE_PATH})
>
>
> SUBDIR(BAR)
>
>
> ---BAR---
> PROJECT(BAR)
> SET(BAR_EXE_PATH CACHE...)
> SET(EXECUTABLE_OUTPUT_PATH ${BAR_EXE_PATH})
>
>
> EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH should remain global,
> as many times you really do want one directory for a combined project.
> For example ParaViewComplete which is a combination of VTK and ParaView
> needs to have one. The main reason for wanting one directory is so
> that dll builds on windows can run without having to set the PATH.
> There is no rpath on windows, however exes will look in the
> current directory
> for dll's.
>
The patch should not hurt such scenarios. In fact anything that is
already working should keep on working in the same manner.
Thanks and Regards,
Nitin
> -Bill
>
>