Le Mon, 10 Nov 2008 16:22:48 +0900,
이명현 [EMAIL PROTECTED] a écrit :
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
Miguel A. Figueroa-Villanueva wrote:
Thanks for the valuable input. I've slimmed down my file a bit and used
the find_package_handle_standard_arg macro. It's attached to this
message. Again feel free to include it in cmake or give more input on
it. (or not, it's working for me now anyway)
If
Jed Brown wrote:
My point about CC and friends is that there are often standard
environment variables for setting this stuff. I think it should be
possible to select the version of packages with one variable. For Qt4,
this is the qmake executable, for PETSc, it is (by convention) PETSC_DIR
2008/11/10 Miguel A. Figueroa-Villanueva [EMAIL PROTECTED]:
Thanks for the valuable input. I've slimmed down my file a bit and used
the find_package_handle_standard_arg macro. It's attached to this
message. Again feel free to include it in cmake or give more input on
it. (or not, it's working
On Mon 2008-11-10 08:23, Bill Hoffman wrote:
So, each find module should have a consistently named variable that can
control the prefix for finding the module. For example, FindFoo.cmake,
would have FOO_DIR. If that environment variable is set and CMake can
not find it, it is an error
Hi people,
Consider the following:
# Forcibly set the value of a cache variable
set( VAR Hello CACHE STRING bla bla FORCE )
# Show in-memory value
message( STATUS VAR=${VAR} )
# Load cached value just in case the above SET
# overwrote only the in-memory value
set( VAR )
# Now show the
Thanks Michael, it's good to hear I'm not alone :-)
On Sun 2008-11-09 20:16, Michael Jackson wrote:
So basically if you don't have the HDF5_INSTALL env variable set then my
module probably will not find it, which is good in that instead of
getting a wrong version of HDF5 you just don't get
Hi people,
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such files, call include_directories,
add_definitions and overrides (under certain circumstances) the
Hi all,
I'm trying to do the following:
file(GLOB PLUGINS plugins/*)
This returns all the absolute paths to the plugins. Which is fine.
But, when I try:
file(GLOB PLUGINS RELATIVE plugins/*)
It gives me an error about file GLOB requires a glob expression after the
directory
Is this a bug
Jed Brown wrote:
Thanks Bill. I'm very encouraged by the response this thread has
generated and optimistic that the Find* modules will become more robust
without undue effort by module writers.
Well, it is not going to happen over night, but I think we are closer to
a plan. I am going to
On Mon, Nov 10, 2008 at 8:51 AM, Bill Hoffman wrote:
Miguel A. Figueroa-Villanueva wrote:
Thanks for the valuable input. I've slimmed down my file a bit and used
the find_package_handle_standard_arg macro. It's attached to this
message. Again feel free to include it in cmake or give more
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
...
UseCGAL.cmake, as all such files, call include_directories,
add_definitions and overrides (under
On Mon, Nov 10, 2008 at 10:09 AM, Bill Hoffman wrote:
Jed Brown wrote:
Thanks Bill. I'm very encouraged by the response this thread has
generated and optimistic that the Find* modules will become more robust
without undue effort by module writers.
Well, it is not going to happen over night,
Hello,
From what I understand try_compile creates a mini CMake project and
compiles a source file.
What variables of the current set of cmake variables are forward to
the temporary project?
What environment is used to execute the temporary project? Is it
possible to set environment
variables for
Jed,
Just to tell you, that you are not alone with that kind of problem. I miss a
solution to that abi problems too.
I have also brought up this question every now and then, but without any
usable solution yet.
Sadly, I do not have the time to provide such a solution...
... well, and yes I
Mathias Fröhlich wrote:
The basic problem is that almost all cmake macros tend to test sideeffects
that in some special cases are related to what you need to test. But only for
special cases.
So testing for the existence of a .so in /usr/lib does in no way tell anything
if you can link with
On Fri, Nov 7, 2008 at 2:12 PM, Christopher Harvey wrote:
Alexander Neundorf wrote:
On Friday 07 November 2008, Christopher Harvey wrote:
Hi list,
I wrote this library finding module. If it's good enough for cmake
please include it. If not let me know what's wrong with it so I can fix
it
Hi,
On Monday 10 November 2008 16:29, Bill Hoffman wrote:
Can you describe exactly what you think autotools does here? I guess
most autotools tests use a try-compile to find a library. Is that what
you are referring to?
Yep.
If you want to link with a library you need to test if you can
Eric Noulard wrote:
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
Hello,
there is the following situation: I use CMake as build control system (Windows
platform, MS Visual Studio) for my own project (A). A depends on a second
project (B). The project-files of B are pre generated and not covered by my
CMake-Scripts. I use INCLUDE_EXTERNAL_MSPROJECT to
Miguel A. Figueroa-Villanueva wrote:
es.
- Add an easy way to create dependent cache variables, that when changed
unset a number of other variables.
A while back I had opened a feature request on the third item:
http://public.kitware.com/Bug/view.php?id=7286
I think it is a fairly simple
Miguel A. Figueroa-Villanueva wrote:
On Mon, Nov 10, 2008 at 10:09 AM, Bill Hoffman wrote:
Jed Brown wrote:
Thanks Bill. I'm very encouraged by the response this thread has
generated and optimistic that the Find* modules will become more robust
without undue effort by module writers.
Mathias Fröhlich wrote:
Hi,
On Monday 10 November 2008 16:29, Bill Hoffman wrote:
Can you describe exactly what you think autotools does here? I guess
most autotools tests use a try-compile to find a library. Is that what
you are referring to?
Yep.
If you want to link with a library you
Le Mon, 10 Nov 2008 12:36:04 +0100,
Steven Van Ingelgem [EMAIL PROTECTED] a écrit :
Hi all,
I'm trying to do the following:
file(GLOB PLUGINS plugins/*)
This returns all the absolute paths to the plugins. Which is fine.
But, when I try:
file(GLOB PLUGINS RELATIVE plugins/*)
The variable CTEST_INITIAL_CACHE is ignored in new-style (CTEST_BUILD()
command based) ctest scripts.
Instead, you should use:
FILE(WRITE ${CTEST_BINARY_DIRECTORY}/CMakeCache.txt
MAKECOMMAND:STRING=nmake -i
CMAKE_MAKE_PROGRAM:FILEPATH=nmake
CMAKE_GENERATOR:INTERNAL=NMake Makefiles
If you don't want to overwrite the CMakeCache.txt file, you can do the
following instead of a FILE(WRITE...). This also works if you don't have an
initial CMakeCache.txt file.
SET(FORCED_CACHE_VALUES
\-DCMAKE_OSX_ARCHITECTURES:STRING=i386;ppc\
\-DCMAKE_BUILD_TYPE:STRING=Release\
)
Hi list,
This is a pretty simple module. I'd like to give back to cmake, even in
a small way. I'll maintain this module myself if it's put into the cmake
core.
Chris.
# This module locates the developer's image library.
# http://openil.sourceforge.net/
#
# This module sets:
# IL_LIBRARY the
I have created a new wiki entry here:
http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules#Proposed_solutions_to_Find.2A_issues
I merge the information in these entries into the above entry:
http://www.cmake.org/Wiki/CMake:Static_libraries
2008/11/7 Alin M Elena [EMAIL PROTECTED]:
Hi,
Sorry for the quoting thing. the cvs one.
It seems that neither CVS HEAD nor CVS CMake-2-6 generates the
package_source target any more...
whereas CMake-2-6-2 do generates the package_source...
I'll wait the next RC before filing a bug :-)
--
Bill Hoffman wrote:
I have created a new wiki entry here:
http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules#Proposed_solutions_to_Find.2A_issues
I merge the information in these entries into the above entry:
http://www.cmake.org/Wiki/CMake:Static_libraries
On Sun 2008-11-09 17:55, Bill Hoffman wrote:
OK, so you have version of libraries that are not in default locations,
how is any build system supposed to find stuff like this?
Of course not automatically, but with minimal hinting. Ideally the user
runs CMake and sees one visible cache entry
Eric Noulard wrote:
2008/11/7 Alin M Elena [EMAIL PROTECTED]:
Hi,
Sorry for the quoting thing. the cvs one.
It seems that neither CVS HEAD nor CVS CMake-2-6 generates the
package_source target any more...
whereas CMake-2-6-2 do generates the package_source...
I'll wait the next RC before
On Monday 10 November 2008, Martin Apel wrote:
...
I recently played around with nightly builds as well. I used to have a
setup for experimental builds, but never could get the svn checkout to
run. With the approach described above, I was finally able
to run checkout from svn from within
On Monday 10 November 2008, Óscar Fuentes wrote:
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
On Monday 10 November 2008, Óscar Fuentes wrote:
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.
Doesn't work, you have to do it the other way round: create a custom target
my-special-clean, do what you
On Monday 10 November 2008, Eric NOULARD wrote:
Le Mon, 10 Nov 2008 16:22:48 +0900,
...
You may try to create your static lib from the top-level CMakeLists.txt
FILE(GLOB_RECURSE SOURCE_FILE_LIST *.cpp)
FILE(GLOB_RECURSE HEADER_FILE_LIST *.h)
ADD_LIBRARY(whatever STATIC ${SOURCE_FILE_LIST}
On Monday 10 November 2008, Bill Hoffman wrote:
Jed Brown wrote:
Thanks Bill. I'm very encouraged by the response this thread has
generated and optimistic that the Find* modules will become more robust
without undue effort by module writers.
Well, it is not going to happen over night,
Hello, Alex.
Alexander Neundorf [EMAIL PROTECTED]
writes:
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.
Doesn't work, you have to do it the other way round: create a custom target
On Monday 10 November 2008, Óscar Fuentes wrote:
Hello, Alex.
Alexander Neundorf [EMAIL PROTECTED]
writes:
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.
Doesn't work, you have to do it the
Consider the following:
C:\Users\myself\Testtype CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project (Test)
message (STATUS ENV{ProgramFiles}=$ENV{ProgramFiles})
C:\Users\myself\Testset ProgramFiles
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program
Alexander Neundorf [EMAIL PROTECTED]
writes:
Doesn't work, you have to do it the other way round: create a custom
target my-special-clean, do what you need, and also execute something
like ${CMAKE_MAKE_COMMAND} directories etc clean
Sadly, this is not acceptable.
Setting the
You have discovered the magic of Windows. Again.
CMake is a 32-bit process. When Windows launches a 32-bit process on a Win64
machine, it gives the 32-bit process C:\ProgramFiles (x86) as the value of
the env var ProgramFiles. But you are testing it from a 64-bit program,
the default cmd.exe on
Hi, my 2c...
2008/11/10 Andreas Pakulat [EMAIL PROTECTED]
On 10.11.08 12:01:13, Fernando Cacciola wrote:
The CGAL library (www.cgal.org) uses cmake as build system. Thus, our
users do:
find_package(CGAL REQUIRED)
include( ${CGAL_USE_FILE} )
There are projects that have headers that are
43 matches
Mail list logo
