That's good point.
Actually on lines 43-45 the variable EXIF_ROOT_DIR is set according to $ENV{EXIF_ROOT_DIR}
only if the first header-file of libexif is found in that folder. The same behaviour if
the variable EXIF_ROOT_DIR is set with -D option, so if you don't set the env one
I'll take a look at the code you sent in your original post and try to see
exactly why it's not working. I might not get to it until the end of the
day, though.
If it worked in VS2008, but not now in VS2010, then we're clearly doing
something different in the generators. I'll find out if it's an i
Ah, I new that would come up. Yeah, they could be renamed. There are only
a dozen or so of them.
I was just trying to migrate the build system to VS2010 in between
projects here at work, and this is the only thing holding me back from a
smooth transition. Changing the extension is certainly an
> You don't need those backslashes there. Try:
> file( MAKE_DIRECTORY "${EXECUTABLE_OUTPUT_PATH}/${Release}/sqldrivers" )
>
That solved the issue.
The reason for my error (besides the headache that I have at the
moment) was that I copied the line from the the next line in the macro
which needs to
I don't think it's stupid. No judgment here. :-)
But can it be renamed, or does this logging library require ".res" as the
file extension?
On Fri, Jan 21, 2011 at 11:22 AM, wrote:
> Well, you're probably going to think this is stupid, but the *.res file is
> not actually a resource file in the
(That made it look like you were trying to create a directory with a literal
" in the name...)
On Fri, Jan 21, 2011 at 11:33 AM, David Cole wrote:
> You don't need those backslashes there. Try:
> file( MAKE_DIRECTORY "${EXECUTABLE_OUTPUT_PATH}/${Release}/sqldrivers" )
>
>
>
> On Fri, Jan 21, 20
You don't need those backslashes there. Try:
file( MAKE_DIRECTORY "${EXECUTABLE_OUTPUT_PATH}/${Release}/sqldrivers" )
On Fri, Jan 21, 2011 at 11:21 AM, John Drescher
wrote:
>
> I am getting a the following error:
>
> CREATING X:/32Bit/VC.90/Qt/StudyManager/bin/Debug/sqldrivers
> CMake Error at C
Well, you're probably going to think this is stupid, but the *.res file is
not actually a resource file in the Microsoft sense of it. It's just a
text file that happens to have the *.res extension. It's a string
localization text file that our logging library knows how to read. It
think it is j
I am getting a the following error:
CREATING X:/32Bit/VC.90/Qt/StudyManager/bin/Debug/sqldrivers
CMake Error at CMake/GetQtRuntime.cmake:21 (file):
file problem creating directory:
X:/CMakeBased/Qt/StudyManager/"X:/32Bit/VC.90/Qt/StudyManager/bin/Debug/sqldrivers"
Call Stack (most recent call
This is similar in nature to
http://public.kitware.com/Bug/view.php?id=11147and friends...
The fix for that issue is ending up being "obj" file specific, though,
because we have a special handler in place for files with "obj" extensions.
Perhaps we need similar handling for "res" files. (They are
This is with both 2.8.3 and 2.8.4-rc1.
On a side note, VS2010 is not trying to compile the *.res file as part of
the executable, because it is marked HEADER_FILE_ONLY, and in addition I
can remove it entirely from the project. Instead, even when the *.res file
appears no where in the solution e
The only thing I might add to it would be something like the following:
# Only set EXIF_ROOT_DIR to the environment variable if
# the user has not specifically set it as a "-D" variable
# on the command line or in CMake-GUI as a CMake Variable.
if ("${EXIF_ROOT_DIR}" STREQUAL "")
SET (EXIF_RO
With some small modifications to some cmake code you can create a self
contained "installation" with your binary and dependent libraries which is
"self contained" in a folder that can be moved any where. I have a project
where I do exactly this.
I have my executable installed in CMAKE_INSTALL_
On Friday 21 January 2011, Michael Hertling wrote:
> On 01/20/2011 07:01 PM, Alexander Neundorf wrote:
> > On Sunday 09 January 2011, Michael Hertling wrote:
...
> >>> I don't really understand why you want to get the LOCATION from your
> >>> target, anyway, the get_target_property works fine if yo
Hello to everyone.
I've written the new module FindEXIF.cmake that looks for libexif and I'd like
to be the
maintainer for this module.
Attached to this email the FindEXIF.cmake. It works correctly on GNU/Linux and
MacOSX,
while on Windows it requires the environment variable EXIF_ROOT_DIR to b
It is a pure terminal application, so you are probably right. However, the old
way to install it was that a user had to first install Fink, then wait a few
hours for the correct gcc version to be installed with gfortran, then download
the correct version of the executable. Or he/she could downlo
Dear CMake users,
I have this BIG project which has tons of subdirectories (many levels).
In each (final) subdirectory, I create targets (executables and libraires).
So I have my top level CMakeLists.txt and one CMakeLists.txt file (which is
also a project) in each subdirectory.
Everything co
IS your application a GUI application or an terminal application? If it is
really a terminal application then you really should NOT be creating an .app
bundle but instead just a plain executable.
___
Mike Jackson www.blu
Thank you so much for your tips and help Michael! My stupid mistake as
you can see it below is that I ran the install target command AFTER the
fixup_bundle. Hence the app did not exist in its location when the
fixup_bundle ran, but when I checked afterwards it all looked as one
would expect.
Hello,
Yesterday, I tried to create subprojects from our existing project
on our dashboard. So, I've read David Cole's article (Issue 10 - July 2009)
and it seems that the labels of a target should match the name of the
subproject, and that with the help of a custom-created CTest driver-file
the r
20 matches
Mail list logo
