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
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
Alexander Neundorf <[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
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} clean
>>
>> Sadly, this is not acceptable.
>
> Setting the ADDITIONA
Consider the following:
C:\Users\myself\Test>type CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project (Test)
message (STATUS ENV{ProgramFiles}=$ENV{ProgramFiles})
C:\Users\myself\Test>set ProgramFiles
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Fi
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
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
> my-speci
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 n
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
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, Ó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
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 ct
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 f
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
http://www.cmake.org/Wiki
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 :-)
-
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
http://www.cmake.org/Wiki/CMake:Multiple_versions
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 na
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\"
)
STR
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
BUILDNAME:ST
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 nee
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.
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 thi
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
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
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 cont
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 t
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 ov
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 override
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
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 up
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
compiler/linker
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
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 err
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
an
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 y
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
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
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 ge
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
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
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 integ
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 a
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 c
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/
>
> CMakeList
44 matches
Mail list logo
