Hi,
I am working in a system where a static library(archive) is build with
source files that are distributed among several directories.
CMakeLists.txt
src /
CMakeLists.txt
*.cpp files
src1/
CMakeLists.txt
*.cpp files
src2/
CMakeLists.txt
*.cpp files
In this setting, I wish to build a static
I wish to execute a command when the `clean' target is invoked. That is,
my command shall execute on addition of the normal target action.
--
Oscar
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Eric NOULARD <[EMAIL PROTECTED]>
writes:
>> The problem is in execute_process. The cmake process created by it is
>> taking variable values from the enclosing cmake, so it uses the same
>> compiler, configure variables, etc.
>
> What do you mean by "variables"?
> CMake one or
> Environment one?
On Nov 9, 2008, at 1:30 PM, Jed Brown wrote:
On Fri 2008-11-07 10:47, Bill Hoffman wrote:
So, currently CMake assumes that the environment you are working
from is
correctly configured. I think adding CMakeModule would go beyond the
scope of what CMake should be doing. Just like you have t
Le Sun, 09 Nov 2008 17:55:12 -0500,
Bill Hoffman <[EMAIL PROTECTED]> a écrit :
> 2. CMake needs a way to easily chain variables together so that you
> can clear stuff out if a dependent variable is changed by the user.
> So, if you have MY_PATH_TO_TOOL=/path/to/tool, and it changes to
> /new/pat
Jed Brown wrote:
Is my environment not `working' simply because I'm asking to link the
versions of libraries that are found at a path other than the system
defaults? Using something else and asking the user to edit the cache is
like ignoring CC and requiring the user to edit CMAKE_C_COMPILER,
Le Sun, 09 Nov 2008 22:24:45 +0100,
Óscar Fuentes <[EMAIL PROTECTED]> a écrit :
> While cross-compiling, I'm trying to avoid depending on previously
> built executables, that is, the cross-compile build should create the
> native utilities it needs. For this, I'm trying
>
> execute_process(
> CO
2008/11/9 Alexander Neundorf <[EMAIL PROTECTED]>:
[...]
> commands can be executed.
>
> IMO this can make setting up Nightly builds much easier.
Looks interesting, I didn't ever thought ctest scripting was done for that.
I did shell scripts for that and was wondering how to do it on Windows :-)
While cross-compiling, I'm trying to avoid depending on previously built
executables, that is, the cross-compile build should create the native
utilities it needs. For this, I'm trying
execute_process(
COMMAND ${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE=Release ${CMAKE_SOURCE_DIR}
WORKING_DIRECTORY ${CX
Hi,
at
http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/KDE4CTestNightlySetup.cmake?revision=882117&view=markup
you can find a script (currently) named KDE4CTestNightlySetup.cmake, which
purpose is to make setting up Nightly builds much easier.
It has to included in a ctest new-style script
On Fri 2008-11-07 10:47, Bill Hoffman wrote:
> So, currently CMake assumes that the environment you are working from is
> correctly configured. I think adding CMakeModule would go beyond the
> scope of what CMake should be doing. Just like you have to have a
> working compiler in your path
No idea??? Problem in my solution is: user defined flags via "gui" are vanished
at configure...
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Sören Freudiger
Gesendet: Donnerstag, 6. November 2008 19:20
An: cmake@cmake.org
Betreff: [CMake] //add
12 matches
Mail list logo