[CMake] FindDCMTK (Offis DICOM Toolkit)

Seeing that someone just mentioned DCMTK, I thought I might as well share an updated version of FindDCMTK so that anyone who needs it can use it right away.  I hope that it will be considered to replace the existing FindDCMTK.cmake .  It works w/ the latest release of DCMTK (3.5.4).  It also suppor

Re: [CMake] cache variable prevents FIND_LIBRARY to be called again :/

On 11/1/06, Tristan Carel <[EMAIL PROTECTED]> wrote: On 11/1/06, Brad King <[EMAIL PROTECTED]> wrote: > Tristan Carel wrote: > > Hi, > > > > The documentation of `FIND_LIBRARY' specify: > > "Once one of these calls succeeds the result variable will be set and > > stored in the cache so that neith

Re: [CMake] cache variable prevents FIND_LIBRARY to be called again :/

On 11/1/06, Brad King <[EMAIL PROTECTED]> wrote: Tristan Carel wrote: > Hi, > > The documentation of `FIND_LIBRARY' specify: > "Once one of these calls succeeds the result variable will be set and > stored in the cache so that neither call will search again." > > Is there a way to avoid this beha

Re: [CMake] cache variable prevents FIND_LIBRARY to be called again :/

On 2006-11-01 15:32-0500 Brad King wrote: Tristan Carel wrote: Hi, The documentation of `FIND_LIBRARY' specify: "Once one of these calls succeeds the result variable will be set and stored in the cache so that neither call will search again." Is there a way to avoid this behavior? I've got a

Re: [CMake] cache variable prevents FIND_LIBRARY to be called again :/

Tristan Carel wrote: > Hi, > > The documentation of `FIND_LIBRARY' specify: > "Once one of these calls succeeds the result variable will be set and > stored in the cache so that neither call will search again." > > Is there a way to avoid this behavior? I've got a FIND_LIBRARY whose > search loca

[CMake] cache variable prevents FIND_LIBRARY to be called again :/

Hi, The documentation of `FIND_LIBRARY' specify: "Once one of these calls succeeds the result variable will be set and stored in the cache so that neither call will search again." Is there a way to avoid this behavior? I've got a FIND_LIBRARY whose search locations depends of the result of a EXE

Re: [CMake] Studio 8 generation of files doesn't use CMAKE_CXX_FLAGS?

Clinton Chau wrote: > You're right, that property is being set in the CMakeList.txt file. > > Given this, how should you make CMAKE_CXX_FLAGS available to the user for > modification in CMakeSetup.exe, without setting the value in CMakeLists.txt? > That is, I always want the user to be able to cus

RE: [CMake] Studio 8 generation of files doesn't use CMAKE_CXX_FLAGS?

> -Original Message- > From: Brad King [mailto:[EMAIL PROTECTED] [...] > > Am I just not understanding how CMake works, since I am new to using > CMake? > > If the CMakeLists.txt file contains > > SET(CMAKE_CXX_FLAGS ...) > > then it always overrides the cached value. The cache value is

Re: [CMake] Setting the C dialect

Filipe Sousa wrote: > Mattias Holm wrote: >> Hi there, >> >> I am new to the list, so excuse me if this has been asked before. >> >> I am trying to figure out if there is a good way of setting the >> language dialect that you are using. For example, I am working with a >> project written in C99

Re: [CMake] Studio 8 generation of files doesn't use CMAKE_CXX_FLAGS?

Clinton Chau wrote: > In order to change the compiler options, and to submit additional > preprocessor defines, I have ended up having to modify the > CMAKE_CXX_FLAGS property in the CMakeLists.txt in the root of the project. > > Am I just not understanding how CMake works, since I am new to using

Re: [CMake] PATH_SUFFIXES doesn't work on x86_64

Brad King wrote: Orion Poplawski wrote: This is apparently because when the suffixes are added to the search list in cmFindBase they are checked for existence before the lib->lib64 mapping is done and since /usr/lib/octave-2.9.9 doesn't exist, it doesn't add it to the search. I'd vote for just

[CMake] Studio 8 generation of files doesn't use CMAKE_CXX_FLAGS?

Hi all,   I encountered a problem and was wondering if anyone else has experienced the same issue.   I’m using CMake 2.4.3 to generate build files under Visual Studio 8 (2005), for the OFFIS DICOM Toolkit source distribution. I have found that modifying the cached value of CMAKE_CXX_FL

Re: [CMake] Setting the C dialect

Mattias Holm wrote: > Hi there, > > I am new to the list, so excuse me if this has been asked before. > > I am trying to figure out if there is a good way of setting the > language dialect that you are using. For example, I am working with a > project written in C99, and thus I need to specif

[CMake] Setting the C dialect

Hi there, I am new to the list, so excuse me if this has been asked before. I am trying to figure out if there is a good way of setting the language dialect that you are using. For example, I am working with a project written in C99, and thus I need to specify this. Sure enough, I can use

[CMake] Re: [vtkusers] VTK/ParaView/ITK BOF at Vis06

Hi, will these presentations be available online or only for the participants of the Vis06? Regards, M.B. Berk Geveci schrieb: Hello Everyone, Kitware will be hosting a VTK / ParaView / ITK "Birds-Of-A-Feather" (BOF) meeting in Baltimore, Maryland as part of the Visualization '06 conference

Re: [CMake] Re: [ANN] New PkgConfig module

Maik Beckmann wrote: > Brad mentioned using "_" as a prefix should be enough. But what about > module authors who uses other modules? The modules may "_"-prefix the > same variable name, i.e. "_to". In that case you should just use the verbose prefix. This is why we call them MACROs and not func

Re: [CMake] [ANN] New PkgConfig module

> Maik Beckmann wrote: > > Hello > > > > I would like to discuss three points > > > > 1. naming conventions > > 2. what if pkg-config sends an error > > 3. protect already defined variables > > Another approach to this problem is to setup the pkgconfig macros so > they can be used by Find*.cmak

Re: [CMake] Re: [ANN] New PkgConfig module

> rather than > > LIBNAME_INCLUDE_DIRS and > > LIBNAME_LINK_LIBS ... > > afais, the latter naming convention is required by Modules/readme.txt Oh, didn't know. > first: > > pkg_config(MYPREFIX found "lib1 >= ??? lib2 >= ??? ...") > > if(NOT found) > > # FATAL_ERROR of looking for altern

[CMake] Re: [ANN] New PkgConfig module

Maik Beckmann <[EMAIL PROTECTED]> writes: > The interface will get a prefix like > pkg_check_modules(LIBNAME ...) > > I would prefer to stick close to the command names, so > > since INCLUDE_DIRECTORIES -> LIBNAME_INCLUDE_DIRECTORIES > since LINK_DIRECTORIES -> LIBNAME_LINK_DIRECTORIES > s

Re: [CMake] DLL not found question

Jacob Foshee wrote: > Perhaps if Find<3rdParty>.cmake or <3rdParty>Config.cmake advertised a > 3rdParty_BIN_DIR or 3rdParty_RUNTIME_DIR this would help? I could try > writing a FIND_RUNTIME_LIBRARY macro if that would help. Some project's modules already do export a FOO_RUNTIME_LIBRARY_DIRS varia

Re: [CMake] PATH_SUFFIXES doesn't work on x86_64

Orion Poplawski wrote: > This is apparently because when the suffixes are added > to the search list in cmFindBase they are checked for existence before > the lib->lib64 mapping is done and since /usr/lib/octave-2.9.9 doesn't > exist, it doesn't add it to the search. I'd vote for just removing the

Re: [CMake] [ANN] New PkgConfig module

Maik Beckmann wrote: > Hello > > I would like to discuss three points > > 1. naming conventions > 2. what if pkg-config sends an error > 3. protect already defined variables Another approach to this problem is to setup the pkgconfig macros so they can be used by Find*.cmake modules. When a use

Re: [CMake] [ANN] New PkgConfig module

Hello I would like to discuss three points 1. naming conventions 2. what if pkg-config sends an error 3. protect already defined variables 1. naming conventions: The interface will get a prefix like pkg_check_modules(LIBNAME ...) I would prefer to