Does anyone have a find script for Ogre3D, or do i need to make one ?
Thanks
Xavier
begin:vcard
fn;quoted-printable:Xavier Larrod=C3=A9
n;quoted-printable:Larrod=C3=A9;Xavier
org:IRISA ;E119 Orange
title:Projet GVT
tel;work:73 28
version:2.1
end:vcard
_
Hi
1. We are using CMake for one year now and we want to thank all who are
involved at the development of CMake.
It really helps us a lot and we save several days in rewriting makefiles for
Linux.
2. are there any changes to the Qt macros? We wrote out own macros for
wrapping moc-files (within a m
Hi,
I'm creating some files with ADD_CUSTOM_COMMAND. Those files are not
compileable but later needed for install.
They're created fine when I use msvc generator but they aren't created with
mingw or on linux.
ADD_CUSTOM_COMMAND(
OUTPUT ${_out}
COMMAND prog ${_in} ${_out}
DEPENDS ${_in}
)
Original-Nachricht
Datum: Thu, 20 Jul 2006 11:43:53 +0200
Von: "Christian Ehrlicher" <[EMAIL PROTECTED]>
An: cmake@cmake.org
Betreff: [CMake] ADD_CUSTOM_COMMAND doesn\'t work as expected
> Hi,
>
> I'm creating some files with ADD_CUSTOM_COMMAND. Those files are not
> compileabl
> > Hi,
> >
> > I'm creating some files with ADD_CUSTOM_COMMAND. Those files are not
> > compileable but later needed for install.
> > They're created fine when I use msvc generator but they aren't created
> > with mingw or on linux.
> >
> > ADD_CUSTOM_COMMAND(
> > OUTPUT ${_out}
> > COMMAND
Dan Mueller wrote:
Hi,
I am trying to compare the computation times of two different
approaches within ITK, using CMake to script the tests. The starting
and ending times are listed in the LastTest.log, so I was planning to
use these to record how long each test takes. Each test could take a
Jan Woetzel wrote:
> Jan Woetzel wrote:
>
>> (1) I think XEmacs is using an xterm but doing his own extar coloring
>> to mark e.g. errors in red. Is that the problem?
> I think the problem should be fixed in CMake to be even more
> "conservative" with coloring, e.g. with a runtime check on env. va
Christian Ehrlicher wrote:
>>> Hi,
>>>
>>> I'm creating some files with ADD_CUSTOM_COMMAND. Those files are not
>>> compileable but later needed for install.
>>> They're created fine when I use msvc generator but they aren't created
>>> with mingw or on linux.
>>>
>>> ADD_CUSTOM_COMMAND(
>>> OUTP
Von: Brad King <[EMAIL PROTECTED]>
> Christian Ehrlicher wrote:
> >>
> >> What kind of files are these ?
> >> Ideally you should add them to the list of sources for the target. If
> they
> >> don't have a source-file suffix, they won't be compiled. Or you could
> use
> >> add_custom_command( main
[EMAIL PROTECTED] wrote:
> It appears that Digital Unix's libc doesn't have snprintf/vsnprintf,
> which are used in quite a few places - mostly in source under the
> Utilities and CTest directories.
I think this is the first time anyone has tried building CMake on
Digital Unix. Officially support
Christian Ehrlicher wrote:
> Von: Brad King <[EMAIL PROTECTED]>
>> Christian Ehrlicher wrote:
>
What kind of files are these ?
Ideally you should add them to the list of sources for the target. If
>> they
don't have a source-file suffix, they won't be compiled. Or you could
>> use
>
Hello,
Actually, there is a vsnprintf/snprintf implementation in
CMake/Utilities/cmtar/compat/snprintf.c.
Andy
Brad King wrote:
[EMAIL PROTECTED] wrote:
It appears that Digital Unix's libc doesn't have snprintf/vsnprintf,
which are used in quite a few places - mostly in source unde
Hi,
I have a bunch of tests that are created with something like this:
ADD_TEST(mytest "executable_dir/${CTEST_CONFIGURATION_TYPE}/mytest.exe")
Running these with "ctest -C Debug" or "ctest -C Release" works fine.
However I want to create a ctest script to build and test my project and
it lo
Hi list,
I have identified a few potentially unsafe operations in cmake's
code. They're mostly related to unchecked buffer sizes. The most
frightening of them is inside cmake.cxx.
Just an example: sprintf(tgtName, "%s%d", graphNodePrefix, cnt++);
It wouldn't be that much of an issue to change t
On 7/20/06, Mike Talbot <[EMAIL PROTECTED]> wrote:
Hi,
I have a bunch of tests that are created with something like this:
ADD_TEST(mytest "executable_dir/${CTEST_CONFIGURATION_TYPE}/mytest.exe")
Running these with "ctest -C Debug" or "ctest -C Release" works fine.
However I want to create a ct
Xavier Larrode wrote:
Does anyone have a find script for Ogre3D, or do i need to make one ?
Did you try asking the Ogre3D crowd? I see some guy has made some posts
in the Ogre3D forums about CMake, but CMake is not officially used by
Ogre3D build. Browsing the CVS sources, it appears to be
Using CMake 2.4.2. Here's my mighty CMakeLists.txt:
ADD_CUSTOM_TARGET(test
COMMAND ${CMAKE_COMMAND} -E echo "It's difficult to handle apostrophes."
)
I used CCMake under Cygwin to generate the Makefile. It dies thus:
Brandon J. Van [EMAIL PROTECTED] ~/echo
$ make test
/bin/sh: -c: line 0: un
> I think this is the first time anyone has tried building CMake on
> Digital Unix. Officially supported platforms have dashboard
submissions:
Ahh, I was afraid of that.
> If you want to try to port the code to that platform we accept patches
> in the bug tracker:
>
> http://www.cmake.org/Bug
>
I'm using CMake 2.4.2 and using the Visual Studio .NET 2003 generator.
When I do
FIND_PROGRAM(MAKEINFO_EXE NAMES makeinfo)
it picks up my MSYS makeinfo, because I have my MSYS tools in my Windows
system path. The exact filename found, as reported by CMakeCache.txt, is
MAKEINFO_EXE:FILEPATH=E
We are getting a strange problem and I want to know if anyone else has seen this.
I am running ctest on a subtree of the library (not the whole library). My repository is at revision 183. When ctest runs for the first time it reverts the repsoitory back to an old version then log message is:
The problem seems to be that the nightly test reverts the repository version to that of the previous day. The continuous test uses the most recent version.
Is this the expected behaviour?
I would have expected that if I run the nightly, it would use the most recent version.
Andrew
--
On Fri, 2006-07-21 at 13:31 +1000, Andrew Maclean wrote:
> The problem seems to be that the nightly test reverts the repository
> version to that of the previous day. The continuous test uses the most
> recent version.
> Is this the expected behaviour?
> I would have expected that if I run the nigh
22 matches
Mail list logo