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
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 user
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
Jacob Foshee wrote:
Perhaps if Find3rdParty.cmake or 3rdPartyConfig.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
variable
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 alternatives ...
...
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 functions.
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.
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 specify
Hi all,
I encountered a problem and was wondering if anyone else has
experienced the same issue.
Im 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
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
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
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, and thus I
-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 just used
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
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
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 locations
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
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 neither call will
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 supports
19 matches
Mail list logo
