I've been distracted and put that aside for a while. I'll see if I can't get
back to it in the coming week...
On Fri, Jun 20, 2008 at 4:16 PM, Bill Hoffman <[EMAIL PROTECTED]>
wrote:
> [EMAIL PROTECTED] wrote:
>
>> On Friday 20 June 2008 8:52:25 am Mike Arthur wrote:
>>
>>> On Wednesday 18 June
On Friday 20 June 2008 2:16:24 pm Bill Hoffman wrote:
> [EMAIL PROTECTED] wrote:
> > On Friday 20 June 2008 8:52:25 am Mike Arthur wrote:
> >> On Wednesday 18 June 2008 21:19:33 you wrote:
> >>> It would probably be easier to get them from QT_QT*_LIBRARY_RELEASE or
> >>> QT_QT*_LIBRARY_DEBUG variab
Sean McBride wrote:
On 6/20/08 5:46 PM, Matthias Riechmann said:
what exactly do I have to do to successfully build my applilcation as a
MacOS X bundle? So far I used the parameter "MACOSX_BUNDLE" for the
ADD_EXECUTABLE command and set a lot of properties using the
MACOSX_BUNDLE_* variables.
[EMAIL PROTECTED] wrote:
On Friday 20 June 2008 8:52:25 am Mike Arthur wrote:
On Wednesday 18 June 2008 21:19:33 you wrote:
It would probably be easier to get them from QT_QT*_LIBRARY_RELEASE or
QT_QT*_LIBRARY_DEBUG variables, and replace the .lib extension with the
.dll.
Thanks, I opted for t
On 6/20/08 5:46 PM, Matthias Riechmann said:
>what exactly do I have to do to successfully build my applilcation as a
>MacOS X bundle? So far I used the parameter "MACOSX_BUNDLE" for the
>ADD_EXECUTABLE command and set a lot of properties using the
>MACOSX_BUNDLE_* variables. The result is inde
Hello.
I have a project that I'm building with CMake and I made my own cmake script
for one of the libraries I'm using (the library is called YARP).
So I created a FindYARP.cmake file which checks whether YARP is installed on
the computer. In my master CMakeLists.txt file I add it to the CMake
On Friday 20 June 2008 8:52:25 am Mike Arthur wrote:
> On Wednesday 18 June 2008 21:19:33 you wrote:
> > It would probably be easier to get them from QT_QT*_LIBRARY_RELEASE or
> > QT_QT*_LIBRARY_DEBUG variables, and replace the .lib extension with the
> > .dll.
>
> Thanks, I opted for this approach
On Fri, Jun 20, 2008 at 11:47 AM, David Cole <[EMAIL PROTECTED]> wrote:
> ADD_CUSTOM_COMMAND to copy the modules to
> "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${CMAKE_CFG_INTDIR}/modules" should
> work...
You may also be able to use the PREFIX hack to change the location where the
target is generated.
Christian Convey wrote:
Hi guys,
From the cmake 2.6 documentation, it sounds to me like
INCLUDE_DIRECTORIES will add another directory to the list of those
searched for header files. In contrast, LINK_DIRECTORIES sounds like
it overwrites, rather than appends to, the previous list of
director
Hi guys,
>From the cmake 2.6 documentation, it sounds to me like
INCLUDE_DIRECTORIES will add another directory to the list of those
searched for header files. In contrast, LINK_DIRECTORIES sounds like
it overwrites, rather than appends to, the previous list of
directories that are searched throu
On Friday 20 June 2008 19:55:55 Mike Arthur wrote:
> On Friday 20 June 2008 16:51:15 Timenkov Yuri wrote:
> > However, if you have complex deployment layout, you should prefer
> > installing your project and running from target location. Trying to make
> > in-source runs may be endless pain, while
On Friday 20 June 2008 16:51:15 Timenkov Yuri wrote:
> However, if you have complex deployment layout, you should prefer
> installing your project and running from target location. Trying to make
> in-source runs may be endless pain, while installing your project may
> require couple of seconds eac
On Friday 20 June 2008 18:48:18 Mike Arthur wrote:
> Part 3 in my never-ending quest to replace our Visual-Studio-based build
> system with CMake has me tearing my hair out...
>
> I've set CMAKE_RUNTIME_OUTPUT_DIRECTORY to bin so everything is build
> correctly in bin/Debug or bin/Release depend
ADD_CUSTOM_COMMAND to copy the modules to
"${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${CMAKE_CFG_INTDIR}/modules" should
work...
On Fri, Jun 20, 2008 at 10:48 AM, Mike Arthur <[EMAIL PROTECTED]> wrote:
> Part 3 in my never-ending quest to replace our Visual-Studio-based build
> system with CMake has me
Hi,
what exactly do I have to do to successfully build my applilcation as a
MacOS X bundle? So far I used the parameter "MACOSX_BUNDLE" for the
ADD_EXECUTABLE command and set a lot of properties using the
MACOSX_BUNDLE_* variables. The result is indeed a directory with an
".app" extension wit
I just discovered that VS 2005 and greater have some per target
configuration files that might be interesting for CMake to create.
Next to each .vcproj file is a .vcproj.CORRIN.hoffman.user file, where
CORRIN is the name of the machine, and hoffman is the name of the user.
These files are not
Part 3 in my never-ending quest to replace our Visual-Studio-based build
system with CMake has me tearing my hair out...
I've set CMAKE_RUNTIME_OUTPUT_DIRECTORY to bin so everything is build
correctly in bin/Debug or bin/Release depending on the project.
What I'm trying to do now is get somethi
This will not work:
IF (${CMAKE_CFG_INTDIR} MATCHES "Debug")
That is not really known until build time. When CMake is run, it
creates a visual studio project that can build Debug, Release, or some
other configuration. So, at cmake time you don't know which ones will
be built.
COMPILE_FL
Am Freitag 20 Juni 2008 14:49:37 schrieb David Cole:
> Regardless of the answer to your original question, these variable names
> simply cannot be changed now.
Sure!
> There are too many scripts that run dashboards that set them as is. The
> best we could do would be to invent duplicate variab
Maik Beckmann wrote:
Am Sonntag 15 Juni 2008 11:35:49 schrieb Maik Beckmann:
Hello,
I wonder if the following name inconsistency is by intention or an
oversight. In cmake scripts there are
CMAKE_SOURCE_DIR
CMAKE_BINARY_DIR
and in ctest the counterparts are called
CTEST_SOURCE_DIRECTORY
Regardless of the answer to your original question, these variable names
simply cannot be changed now. There are too many scripts that run dashboards
that set them as is. The best we could do would be to invent duplicate
variable names that are consistent, but then we'd have duplicates and people
w
Am Sonntag 15 Juni 2008 11:35:49 schrieb Maik Beckmann:
> Hello,
>
> I wonder if the following name inconsistency is by intention or an
> oversight. In cmake scripts there are
> CMAKE_SOURCE_DIR
> CMAKE_BINARY_DIR
> and in ctest the counterparts are called
> CTEST_SOURCE_DIRECTORY
> CTEST_B
Salut Benjamin,
On Fri, Jun 20, 2008 at 8:03 AM, Benjamin Depardon
<[EMAIL PROTECTED]> wrote:
> In fact I'm using the TAU compiler, which is a script that modify the code
> before compiling it with a standard compiler (gcc).
> My problem is that CMake adds a-D_EXPORTS flag before any
> of my flags
23 matches
Mail list logo