Hi list,
I'm having a new problem with CMake; if anyone cares/remembers the
past one, it was just a stupid typo in the filename.
I have the file check_openal_spec_version_1_1.cpp which contains:
#define AL_VERSION_1_1
#define AL_VERSION_1_0
int main() {
#ifdef AL_VERSION_1_1
Thanks. VERBATIM was the problem. After, removing it, the code works
perfectly. Thanks!
Anyway, I am a little bit puzzled with documentation, as it states:
> In the future VERBATIM may be enabled by default. The only reason
> it is an option is to preserve compatibility with older CMake code.
Bill Hoffman wrote:
> Dave Milter wrote:
>> cmake version 2.4-patch 8
>>
>> and it not regenerates ui_foo.hpp after uncomment foo2.cpp,
>> so it is regression, or previous (good for me behaviour) cause many bugs?
>>
> It is not a bug. It was a bug fix. If you changed a custom command in
> 2.4 the
> Why not LUA51_FOUND?
> Is this valid?
> I think not.
> Attached patch changes variable name LUA50_FOUND to LUA51_FOUND.
Yes, that looks like a bug. That FIND_PACKAGE_HANDLE_STANDARD_ARGS
stuff is new to me. Somebody else added it and must have done the
normal copy/paste thing/bug. I checked in t
Try:
SET(CPACK_PACKAGE_ICON "${CMAKE_SOURCE_DIR}test.bmp")
There is a "bug" in the NSIS installer that refuses to extract the file name
properly when there are only "/" forward slashes in the file name...
HTH,
David
On Sun, Jun 1, 2008 at 5:48 PM, Torsten Grote <[EMAIL PROTECTED]> wrote:
Your initial attempt looks reasonable... Did you try it without the
"VERBATIM" argument to the ADD_CUSTOM_COMMAND?
This sort of copy command should work if invoked from Visual Studio, even
with the $(OutDir) reference...
HTH,
David
On Sun, Jun 1, 2008 at 10:29 AM, Pečiva Jan <[EMAIL PROTECTED]
On Sunday 01 June 2008 3:02:11 pm Christian Ehrlicher wrote:
> Alexander Neundorf schrieb:
> > On Thursday 29 May 2008, Christian Ehrlicher wrote:
> >> Tanguy Krotoff schrieb:
> >>> On Thu, May 29, 2008 at 8:48 PM, <[EMAIL PROTECTED]> wrote:
> >>> The bug that I got with QT_DEBUG/QT_NO_DEBUG not b
Ahhh nevermind, the implementation changed in cmake 2.6 but interface
remains the same.
this is working out of the box, nice !
Sorry for the noise,
-Mathieu
On Mon, Jun 2, 2008 at 3:48 PM, Mathieu Malaterre
<[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I believe there is a new way to test endianne
Hi there,
I believe there is a new way to test endianness with cmake. I was using:
INCLUDE (${CMAKE_ROOT}/Modules/TestBigEndian.cmake)
TEST_BIG_ENDIAN(GDCM_WORDS_BIGENDIAN)
But this does not work when using mingw32 compiler on a linux box.
Thanks !
--
Mathieu
__
Hi, cmakers!
I've tried to find lua through FindLua51 module, but this module seems
to be buggy.
I have lua-5.1 but after include(FindLua51) I have LUA50_FOUND "true".
Why not LUA51_FOUND?
Is this valid?
I think not.
Attached patch changes variable name LUA50_FOUND to LUA51_FOUND.
PS:
Even bette
Dave Milter wrote:
Recently I try not cvs version with examples that I sent with previous email:
$ cmake --version
cmake version 2.4-patch 8
and it not regenerates ui_foo.hpp after uncomment foo2.cpp,
so it is regression, or previous (good for me behaviour) cause many bugs?
It is not a bug. It
Hi,
did anybody integrate the ACE_TAO corba library in a CMake project?
Within the the shipped version of cmake I didn't find a file like
"FindAceTao.cmake" but maybe someone assembled one before?
Matthias
--
Dipl.-Inform. Matthias Riechmann
Institut für Prozessrechentechnik, Automation
12 matches
Mail list logo