Bill Hoffman wrote:
Naram Qashat wrote:
I have a CMake project that I have been testing with various verisons
of CMake 2.4.x and 2.6.x to make sure it works as far back as 2.4.0,
due to not knowing what version of CMake our users will be using since
a lot of them use shells. In some instances,
On Dienstag 10 März 2009 20:56:17 Alexander Neundorf wrote:
> Or you could test whether e.g. /usr/lib64 exists, and if so, also use
> lib64.
This was an good idea.Now it runs perfectly :-)
--
Sincereley Yours
Sascha Manns
openSUSE Build Service
openSUSE Marketing Team
Maifeldstrasse 10
D-56 727 M
Naram Qashat wrote:
I have a CMake project that I have been testing with various verisons of
CMake 2.4.x and 2.6.x to make sure it works as far back as 2.4.0, due to
not knowing what version of CMake our users will be using since a lot of
them use shells. In some instances, I have to read lines
I have a CMake project that I have been testing with various verisons of CMake
2.4.x and 2.6.x to make sure it works as far back as 2.4.0, due to not knowing
what version of CMake our users will be using since a lot of them use shells.
In some instances, I have to read lines from a file using a
On Tue, Mar 10, 2009 at 3:54 PM, Tristan Carel wrote:
> On Tue, Mar 10, 2009 at 23:42, James Bigler wrote:
> > Is there a way to discover if a path is a relative path or not?
> >
> > I need to make sure that all paths are absolute for a given application,
> and
> > I can be given either relative
On Tue, Mar 10, 2009 at 23:42, James Bigler wrote:
> Is there a way to discover if a path is a relative path or not?
>
> I need to make sure that all paths are absolute for a given application, and
> I can be given either relative or absolute paths to files. If I'm given a
> relative path I want
Is there a way to discover if a path is a relative path or not?
I need to make sure that all paths are absolute for a given application, and
I can be given either relative or absolute paths to files. If I'm given a
relative path I want to prepend ${CMAKE_CURRENT_SOURCE_DIR} to make it
absolute, b
Hello Alexander,
is this right?
SET( CONFIGFILE_PATH /etc/freeremoted CACHE PATH "Path find config file"
FORCE )
SET( MODULEFILE_PATH /usr/lib CACHE PATH "Path find module file" FORCE)
option(USE_LIB64_DIR "Enable this option to use lib64 instead of lib/"
FALSE)
Or must i run this Option extra
On Tuesday 10 March 2009, Sascha 'saigkill' Manns wrote:
> Hello Mates,
>
> i'm Sascha Manns from Germany. I'm new to the List, and i hope that i
> can learn more about CMake.
> Actually i'm building for the openSUSE Build Service an Package called
> "freeremote".
>
> The Package has the following
Hello Mates,
i'm Sascha Manns from Germany. I'm new to the List, and i hope that i
can learn more about CMake.
Actually i'm building for the openSUSE Build Service an Package called
"freeremote".
The Package has the following in the CMakeLists.txt:
SET( CONFIGFILE_PATH ${PREFIX}/etc/freeremoted
Thanks again Eric for the update... I pulled the cpack source code and
started looking through it and came to the same conclusion. Additionally
I ran into a message on the boards about the PACKAGE_SOURCE not being
included in the cmake build. Everything started making sense shortly
after I disc
On Monday 09 March 2009 12:01:23 Hendrik Sattler wrote:
> Andreas Schneider schrieb:
> > My problem is that cmake thinks that it is a windows version...
>
> No, it still knows that it runs on Linux and can use the native tools if
> you tell it so in the toolchain file.
Strange.
>
> > So you succe
Jussi Pakkanen wrote:
On Mon, Mar 9, 2009 at 4:03 PM, Brad King wrote:
do not perform very well in the VS IDE (this is not CMake, but the VS
IDE implementation). The definitions will work, but they cause the IDE
to use a separate invocation of the compiler for every source file
instead of shar
John Biddiscombe wrote:
Brad
BTW, the only reason CMake needs to order the directories is because
of compatibility with how CMake 2.4 ordered them. You must be setting
CMP0003 to OLD. If you set it to NEW you should never see this warning.
That seems to have solved the problem.
On second t
2009/3/10 Sharon Melamed
> Hi,
>
>
>
> My main CmakeList.txt file look like this:
>
>
>
> cmake_minimum_required (VERSION 2.6)
>
> project (vos)
>
>
>
> add_subdirectory (system BUILD)
>
> add_subdirectory (osal BUILD)
>
> add_subdirectory (logger BUILD)
>
> add_subdirectory (loggerConfigTool B
Upon further consideration, I think fixing the codeblocks project file
is probably too specific of a fix. After all, the only way to come
across this issue is if you are cross-compiling, in which case you need
to write a toolchain file anyway. The problem here, IMHO, is that there
are insufficient
Brad
BTW, the only reason CMake needs to order the directories is because
of compatibility with how CMake 2.4 ordered them. You must be setting
CMP0003 to OLD. If you set it to NEW you should never see this warning.
That seems to have solved the problem.
Thanks
JB
(I have CMake policy stat
Eric Noulard wrote:
I should stop writing totally wrong advices for this for a while.
Let us know when you're going to start giving wrong advice again. Just
so we know. ;-)
--
/Jesper
___
Powered by www.kitware.com
Visit other Kitware open-sourc
2009/3/9 Eric Noulard :
>
> My mistake, I've cut the wrong part, sorry about that
>
> CPACK_SOURCE_FILES was meant to be CPACK_IGNORE_FILES
>
> you want to ignore files in BINARY package so the var to use is
> CPACK_IGNORE_FILES
>
> when you want to ignore files in a SOURCE pacakge then you should
-- Forwarded message --
From: ankit jain
Date: 2009/3/10
Subject: Re: [CMake] install question
To: Sharon Melamed
2009/3/10 Sharon Melamed
>Hi,
>
>
>
> My main CmakeList.txt file look like this:
>
>
>
> cmake_minimum_required (VERSION 2.6)
>
> project (vos)
>
>
>
> add_su
Hi,
My main CmakeList.txt file look like this:
cmake_minimum_required (VERSION 2.6)
project (vos)
add_subdirectory (system BUILD)
add_subdirectory (osal BUILD)
add_subdirectory (logger BUILD)
add_subdirectory (loggerConfigTool BUILD)
add_subdirectory (voltSyslogd BUILD)
add_subdi
21 matches
Mail list logo