Thanks Eric, that helped! It also built without any errors (I didn't use
standard configuration but replaced all /MD with /MT and /MDd with /MTd).
Am 14.02.2013 19:55, schrieb Eric Noulard:
2013/2/14 David Cole :
Looks like the values of CPACK_RESOURCE_FILE_README and
CPACK_RESOURCE_FILE_LICEN
I'm slowly realizing the gravity of this behavior:
if(build_system STREQUAL "windows")
...
endif()
If someone creates a variable named "windows", then this code will not work
as intended.
I'm starting to convert our scripts to use this hopefully foolproof
alternative:
string(COMPARE EQUAL "${bu
On 2013-02-14 16:44, Shaun Williams wrote:
I learned something very valuable today about cmake after getting an
unexpected result with STREQUAL:
set(foo bar)
...
set(baz foo)
...
if("${baz}" STREQUAL "bar") # This evaluates to true.
...
I expected it to be false, because I was trying to get baz
Never mind, I get it. What a landmine!
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubs
Uh, why are you talking about STREQUAL when the problem is with set(baz
foo)? It should set baz to "foo" not "bar" because there are no ${} around
foo.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep message
Hi,
I learned something very valuable today about cmake after getting an
unexpected result with STREQUAL:
set(foo bar)
...
set(baz foo)
...
if("${baz}" STREQUAL "bar") # This evaluates to true.
...
I expected it to be false, because I was trying to get baz's value ("foo")
to compare with "bar".
2013/2/14 David Cole :
> Looks like the values of CPACK_RESOURCE_FILE_README and
> CPACK_RESOURCE_FILE_LICENSE are not set to full path values. Since the
> directory may be different when CPack runs, they should be specified as full
> path values, i.e. "${CMAKE_CURRENT_SOURCE_DIR}/README" instead o
Done. Although I am not checking for version numbers as cmake already
does this with cmake_minimum_required.
Am Donnerstag, den 14.02.2013, 09:56 -0600 schrieb Kent Williams:
> This is a good start. There's only one problem: What happens if CMake
> isn't installed. Searching for a proper version
Slight correction below. CMAKE_GENERATOR is a separate argument to the
ExternalProject_Add function, and I had embedded it incorrectly as a
-G option in CMAKE_ARGS.
On Thu, Feb 14, 2013 at 11:21 AM, Patrick Johnmeyer
wrote:
>
> #
> include(ExternalProject)
>
> ExternalProject_Add(MyProjectDeb
Here's a follow-up.
I was unable to get Jean-Christophes modification of Ansis' solution
working. (I definitely did not want to repeat the install directives in
this rather large project.) The "-DCMAKE_BUILD_TYPE" lines don't really
accomplish anything when building with Visual Studio. I was makin
So patch FindDCMTK/FindTIFF in such a way that it add zlib to the dependencies,
use that, and send the patch to your local maintainer?
On 2013-14-02, at 17:01:53 , Kent Williams wrote:
> @Nick find_package(DCMTK) does an OK job. The specific issue I ran into is
> that TIFF depends on Zlib and
@Nick find_package(DCMTK) does an OK job. The specific issue I ran into is
that TIFF depends on Zlib and that dependency isn't pulled through into
DCMTK's dependencies.
The FindDCMTK.cmake that is in the current CMake distro has issues.
@Ansis -- if all I cared about was getting one package buil
This is a good start. There's only one problem: What happens if CMake
isn't installed. Searching for a proper version of CMake should be dine in
the script as well.
It should also generate a config.status file. This need not be incredibly
sophisticated, but since autoconf always generates one,
If I guessed right, your problem is linker errors when building your
project. My solution is to just manually add whatever extra
target_link_libraries are needed to shut the linker up and move on.
On Thu, Feb 14, 2013 at 5:48 PM, Nick Overdijk wrote:
> I don't really get your specific problem..
Hello Bart,
have you tried setting OpenCV_DIR before calling find_package()? I'm
basing this on http://opencv.willowgarage.com/wiki/FindOpenCV.cmake
Most package Find.cmake scripts look if _DIR is set to a valid
directory and look there first for all the libraries before checking
default insta
I don't really get your specific problem... CMake can find and install ITK and
DCMTK just fine here? (I had to manipulate the linker-order of DCMTK a bit but
that's almost to be expected, sadly).
You're saying that when you find_package(DCMTK) it's libraries doesn't include
some library it need
On 02/14/2013 04:35 PM, Andreas Stahl wrote:
Hello Bart,
have you tried setting OpenCV_DIR before calling find_package()? I'm
basing this on http://opencv.willowgarage.com/wiki/FindOpenCV.cmake
Most package Find.cmake scripts look if _DIR is set to a valid
directory and look there first for all
The specific problem I'm trying to solve:
Build DCMTK library, along with libraries upon which it depends, for use by
ITK as a 'system library'
The problem: Setting up the External Projects is simple enough; the problem
is that the revision/configuration of TIFF -- 3.9.4 -- by default requires
ZL
Looks like the values of CPACK_RESOURCE_FILE_README and
CPACK_RESOURCE_FILE_LICENSE are not set to full path values. Since the
directory may be different when CPack runs, they should be specified as full
path values, i.e. "${CMAKE_CURRENT_SOURCE_DIR}/README" instead of "README".
Is that the pro
Hi Shirish,
Waiting for the release, you could simply download the latest nightly build.
See http://www.cmake.org/files/dev/?C=M;O=D
This link was obtained from the CMake website (CMake -> Resources ->
Download -> Current development)
Hth
Jc
On Thu, Feb 14, 2013 at 8:23 AM, shirish शिरीष wrote
Hi all,
I get the following two errors when I try to generate the Visual Studio
2010 build files for MySQL Connector/C 6.0.2 with CMake 2.8.10.2 on
Windows 7 x64.
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CPack.cmake:395 (message):
CPack package description f
Hi all,
Newbie on the list. I am turned off delivery as I've too many
projects (in which I'm interested) from which I get mail hence being
turning them off. Hence please CC me if somebody replies.
From mantis it seems it's gonna be a long time for 2.8.11 to hit .
http://public.kitware.com/
Richard Wiedenhöft wrote:
Yes, but providing a familiar interface for building source tarballs
is
imho a good thing. It does not prevent you from configuring your
sources
with the cmake-command itself.
Furthermore such a script is necessary for compliance with the GNU
Coding Standards.
See ht
Am Donnerstag, 14. Februar 2013, 12:14:57 schrieb Richard Wiedenhöft:
> Yes, but providing a familiar interface for building source tarballs is
> imho a good thing. It does not prevent you from configuring your sources
> with the cmake-command itself.
>
> Furthermore such a script is necessary for
On 02/14/2013 12:26 PM, Andreas Haferburg wrote:
Does CMake find 2.4.3 if you remove 2.3.1? CMake probably doesn't even
look in /tmp/. You could try moving it to /usr/share/OpenCV-2.4.3/.
If the version arg doesn't work, I think your best bet is to use a
naming convention for the library directo
Does CMake find 2.4.3 if you remove 2.3.1? CMake probably doesn't even look in /tmp/. You could try
moving it to /usr/share/OpenCV-2.4.3/.
If the version arg doesn't work, I think your best bet is to use a naming convention for the library
directories (or create symlinks), e.g. --, then use tha
Yes, but providing a familiar interface for building source tarballs is
imho a good thing. It does not prevent you from configuring your sources
with the cmake-command itself.
Furthermore such a script is necessary for compliance with the GNU
Coding Standards.
See http://www.gnu.org/prep/standard
Hi Bart.
When you look into the documentation of find_package() (in its
Configure mode), you'll find a list of paths and prefixes the find
machanism uses. You should be able to set some of those prefixes to
where your local installation of OpenCV is.
Petr
On Thu, Feb 14, 2013 at 12:09 PM, Bart V
On 02/14/2013 11:47 AM, Andreas Haferburg wrote:
Have you tried specifying the version?
FIND_PACKAGE(OpenCV 2.2.0 EXACT REQUIRED)
FIND_PACKAGE(OpenCV 2.4.0 EXACT REQUIRED)
Not sure if the FindOpenCV script can handle the version argument.
Andreas
Doesn't seem to work. I have 2.4.3 installe
So, it's for, for example, Slackware or Gentoo users, who install
everything from source and have the ./configure & make & make install combo
ingrained in their motor memory?
On Thu, Feb 14, 2013 at 10:59 AM, Richard Wiedenhöft <
richard.wiedenho...@gmail.com> wrote:
> Hello,
>
> I recently star
Have you tried specifying the version?
FIND_PACKAGE(OpenCV 2.2.0 EXACT REQUIRED)
FIND_PACKAGE(OpenCV 2.4.0 EXACT REQUIRED)
Not sure if the FindOpenCV script can handle the version argument.
Andreas
On 14.02.2013 11:42, Bart Vandewoestyne wrote:
Hello list,
To compile and link my code with t
Hello list,
To compile and link my code with the OpenCV library, I use
find_package( OpenCV REQUIRED )
...
add_executable(framecountertest framecountertest.cpp)
target_link_libraries(framecountertest ${OpenCV_LIBS})
and this works just fine: the OpenCV library that got installed using my
packa
Hello,
I recently started writing a configure shell-script that is calling
cmake and accepts options similar to the autotools configure script.
https://github.com/Richard-W/cmake-configure-wrapper
Maybe it is useful to some of you.
As of now it is only supporting the CC, CXX and --prefix option
33 matches
Mail list logo
