James Bigler wrote:
On Fri, Oct 2, 2009 at 9:32 AM, Bill Hoffman wrote:
Sean McBride wrote:
On 10/2/09 10:40 AM, Bill Hoffman said:
We did change CMake. Before we used to hard code the build archs into
the file (i386, ppc, etc.). We now use a variable that Xcode uses,
something like $(DEF
On Fri, Oct 2, 2009 at 9:32 AM, Bill Hoffman wrote:
> Sean McBride wrote:
>>
>> On 10/2/09 10:40 AM, Bill Hoffman said:
>>
>>> We did change CMake. Before we used to hard code the build archs into
>>> the file (i386, ppc, etc.). We now use a variable that Xcode uses,
>>> something like $(DEFAUL
Sean McBride wrote:
On 10/2/09 10:40 AM, Bill Hoffman said:
We did change CMake. Before we used to hard code the build archs into
the file (i386, ppc, etc.). We now use a variable that Xcode uses,
something like $(DEFAULT_ARCH) different name, but you get the idea. If
that is not defined f
I thought there was some code to try and find out where Xcode was
installed added to CMake. I think I was the one who helped write it.
Whether that got committed to the repo is another question.
http://www.itk.org/Bug/view.php?id=6195
Support for non-standard Xcode installation was added to
On 10/2/09 10:40 AM, Bill Hoffman said:
>We did change CMake. Before we used to hard code the build archs into
>the file (i386, ppc, etc.). We now use a variable that Xcode uses,
>something like $(DEFAULT_ARCH) different name, but you get the idea. If
>that is not defined for some reason for
Sean McBride wrote:
On 10/1/09 11:17 PM, James Bigler said:
Well, it worked just fine with CMake 2.4.6, so wouldn't this be a
regression?
I guess. Or possibly you were lucky it ever worked (as in, relying on
undefined behaviour that changed). I have no idea. :)
I just found it a little od
On 10/1/09 11:17 PM, James Bigler said:
>Well, it worked just fine with CMake 2.4.6, so wouldn't this be a
>regression?
I guess. Or possibly you were lucky it ever worked (as in, relying on
undefined behaviour that changed). I have no idea. :)
I just found it a little odd that you would be u
James Bigler wrote:
Well, it worked just fine with CMake 2.4.6, so wouldn't this be a
regression?
The reason I haven't upgraded Xcode is that the updater never presented
it, and I don't really check for updates.
We are unable to reproduce this...
You said you did this:
I used --debug-tr
Well, it worked just fine with CMake 2.4.6, so wouldn't this be a
regression?
The reason I haven't upgraded Xcode is that the updater never
presented it, and I don't really check for updates.
James
On Oct 1, 2009, at 3:40 PM, "Sean McBride"
wrote:
James,
I'm curious why you're using
James,
I'm curious why you're using Xcode 3.0 on 10.5.8. Why not use Xcode
3.1.4? Perhaps it's actually Xcode's fault and the bug is already fixed.
On 10/1/09 4:37 PM, James Bigler said:
>So was anyone else able to reproduce this issue?
>
>James
>
>On Tue, Sep 29, 2009 at 10:07 AM, James Bigl
So was anyone else able to reproduce this issue?
James
On Tue, Sep 29, 2009 at 10:07 AM, James Bigler wrote:
> On Tue, Sep 29, 2009 at 9:40 AM, Bill Hoffman
> wrote:
>>
>> James Bigler wrote:
>>>
>>> Silly me. That wasn't a very helpful bug report.
>>>
>>> I updated CMake from CVS last night a
On Tue, Sep 29, 2009 at 9:40 AM, Bill Hoffman wrote:
> James Bigler wrote:
>
>> Silly me. That wasn't a very helpful bug report.
>>
>> I updated CMake from CVS last night at approximately 9 PM MDT.
>>
>> I have XCode 3.0 installed.
>>
>> OSX is version 10.5.8.
>>
>> I also just verified that I ha
James Bigler wrote:
Silly me. That wasn't a very helpful bug report.
I updated CMake from CVS last night at approximately 9 PM MDT.
I have XCode 3.0 installed.
OSX is version 10.5.8.
I also just verified that I have the same problem with CMake 2.8 RC 1.
James
On Tue, Sep 29, 2009 at 5:04 A
Silly me. That wasn't a very helpful bug report.
I updated CMake from CVS last night at approximately 9 PM MDT.
I have XCode 3.0 installed.
OSX is version 10.5.8.
I also just verified that I have the same problem with CMake 2.8 RC 1.
James
On Tue, Sep 29, 2009 at 5:04 AM, David Cole wrote:
Which TOT is the one you mean?http://acronyms.thefreedictionary.com/TOT
What day did you update CMake from CVS?
What Xcode version?
What Mac OSX version?
On Tue, Sep 29, 2009 at 12:17 AM, James Bigler wrote:
> I tried this with a fairly simple example with CMake cvs TOT. Any ideas?
>
> CMakeLi
I tried this with a fairly simple example with CMake cvs TOT. Any ideas?
CMakeLists.txt:
cmake_minimum_required(VERSION 2.6)
project(my_include_directories)
$ /code/cmake-cvs/install/bin/cmake ../ -G Xcode
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check
Yes, I filed this as bug #7470
(http://public.kitware.com/Bug/view.php?id=7470). Thanks for following
up!
Greg Peele
From: David Cole [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2008 2:16 PM
To: Doug Gregor
Cc: Gregory Peele ARA/CFD; cmake@cmake.org
Subject: Re: [CMake] CMake
Was there ever a bug filed on this? If so, what's the issue number in the
bug tracker?
Thx,
David Cole
On Mon, Jul 28, 2008 at 7:15 AM, Doug Gregor <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 25, 2008 at 7:56 PM, Gregory Peele ARA/CFD <[EMAIL PROTECTED]>
> wrote:
> > I'm really pleased with the comp
On Fri, Jul 25, 2008 at 7:56 PM, Gregory Peele ARA/CFD <[EMAIL PROTECTED]>
wrote:
> I'm really pleased with the component-based CPack installer with the NSIS
> backend, and am currently using the July 24th CVS snapshot of CMake to take
> advantage of it. Today I ran into a puzzler though. Some
I'm really pleased with the component-based CPack installer with the
NSIS backend, and am currently using the July 24th CVS snapshot of
CMake to take advantage of it. Today I ran into a puzzler though.
Some of the files I'm installing have spaces in the relative path, and
the NSIS script contain
On Monday 25 February 2008, Frederik Deweerdt wrote:
> Hi all,
>
> I've encountered a problem generating RPMs with the latest
> CVS: apparently, some versions of rpmbuild (ours is 4.2.2) do
> the pre-processing even when the variable to replace is inside
> commentaries.
>
> In CPackRPM.cmake, the %
Hi all,
I've encountered a problem generating RPMs with the latest
CVS: apparently, some versions of rpmbuild (ours is 4.2.2) do
the pre-processing even when the variable to replace is inside
commentaries.
In CPackRPM.cmake, the %install directive is found twice (lines 192 and
198), thus rpmbuild
On 28.01.08 08:35:30, Brad King wrote:
> Andreas Pakulat wrote:
>> Ok, I'll inform kde-buildsystem as this will probably need some time to
>> be fixed...
>
> Thanks. Hopefully they can get it in a 4.0.1 patch release or something.
There's one other thing that may have gone unnoticed under all the
Andreas Pakulat wrote:
Ok, I'll inform kde-buildsystem as this will probably need some time to
be fixed...
Thanks. Hopefully they can get it in a 4.0.1 patch release or something.
The linking implementation is going through an overhaul so there have been
more changes since your original post
On 27.01.08 20:40:05, Brad King wrote:
> Andreas Pakulat wrote:
>> Also I noticed that the linker line doesn't contain an option that gives
>> gcc the kde4 library dir to search for kde libs. This is another thing
>> which broke things for me here, i.e. ld complains that -lsolid cannot be
>> found
On 27.01.08 20:30:34, Brad King wrote:
> If something is using the export_library_dependencies file then there must
> be a project outside kdelibs involved. Are you using the same version of
> CMake for both trees?
I thought I did, but apparently I didn't. At least I can't reproduce
this part a
Andreas Pakulat wrote:
Also I noticed that the linker line doesn't contain an option that gives
gcc the kde4 library dir to search for kde libs. This is another thing
which broke things for me here, i.e. ld complains that -lsolid cannot be
found (as you can see below there's a solid entry in the
Andreas Pakulat wrote:
Anyway, the latest cvs version from cmake (update 2 hours ago) produces
the following entries in KDELibsDependencies.cmake. This file is
generated using the export_library_dependecies() command:
SET(kdecore_LIB_DEPENDS
"general;/home/andreas/qt-copy/lib/libQtCore.so;gener
On 27.01.08 14:50:13, Aleix wrote:
> I am compiling KDE with the cmake-cvs version.
>
> I had the same problem when I switched and, IIRC, I had to (nuke every
> builddir and) recompile whole KDE because of this -lgeneral thing, but
> this was back in the summer so I think it is not a new issue.
I
Hi andreas,
I am compiling KDE with the cmake-cvs version.
I had the same problem when I switched and, IIRC, I had to (nuke every
builddir and) recompile whole KDE because of this -lgeneral thing, but
this was back in the summer so I think it is not a new issue.
Bye!
Aleix
On 1/26/08, Andreas Pa
Hi,
not sure wether this is really a fault in cmake, or just some changed
behaviour which needs changes in kdelibs cmake code.
Anyway, the latest cvs version from cmake (update 2 hours ago) produces
the following entries in KDELibsDependencies.cmake. This file is
generated using the export_librar
Using CVS from Dec 15, 2007:
540:[EMAIL PROTECTED]:Build]$ bin/cmake --help-variable
"CMAKE__LINK_EXECUTABLE"cmake version 2.5-20071215
Argument "CMAKE__LINK_EXECUTABLE" to --help-variable is not a
defined variable. Use --help-variable-list to see all defined
variables.
b
Here is another one:
531:[EMAIL PROTECTED]:Build]$ bin/cmake --help-module-list
cmake version 2.5-20071213
Internal error: Modules list is empty.
532:[EMAIL PROTECTED]:Build]$ bin/cmake --version
cmake version 2.5-20071213
--
Mike Jackson Senior Research Engineer
Innovative Management & Tec
Mike Jackson wrote:
doh.. cmake 2.4.7 was on my path. I should have done:
bin/cmake --help-variable-list /tmp/variable.html
sorry for the noise
Actually, you did find a bug, and I have fixed the docs with the wrong
case for the v.
-Bill
___
CMak
doh.. cmake 2.4.7 was on my path. I should have done:
bin/cmake --help-variable-list /tmp/variable.html
sorry for the noise
--
Mike Jackson Senior Research Engineer
Innovative Management & Technology Services
On Dec 13, 2007, at 3:09 PM, Bill Hoffman wrote:
Mike Jackson wrote:
Not sure
Mike Jackson wrote:
Not sure if this is know but using today's cvs I tried the following:
504:[EMAIL PROTECTED]:bin]$ cmake --help-Variable-list /tmp/out.txt
CMake Error: The source directory "/tmp/out.txt" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
Bug
Mike Jackson wrote:
> Not sure if this is know but using today's cvs I tried the following:
>
> 504:[EMAIL PROTECTED]:bin]$ cmake --help-Variable-list /tmp/out.txt
> CMake Error: The source directory "/tmp/out.txt" does not exist.
> Specify --help for usage, or press the help button on the CMake G
Not sure if this is know but using today's cvs I tried the following:
504:[EMAIL PROTECTED]:bin]$ cmake --help-Variable-list /tmp/out.txt
CMake Error: The source directory "/tmp/out.txt" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
Bug?
Also, there is a s
I get that same message if I come from behind certain firewalls. I
usually have to go find a local free wifi access point to download/
update. Other than that.. no idea.
--
Mike Jackson Senior Research Engineer
Innovative Management & Technology Services
On Nov 29, 2007, at 2:18 PM, Jesse
I am trying to get the cmake source with cvs, but I keep getting connection
refused. I am using this command
*cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/CMake login
*and the password cmake. Any ideas?
___
CMake mailing list
CMake@cmake.org
http://www.cm
I think this is a mismatch in the curses headers and the libraries.
You can disable curses or edit your cache and tell cmake
to use a different one. Or you can disable curses by
setting this to false:
BUILD_CursesDialog
If you disable curses, you will not get ccmake.
This problem came up before
Hi,I am trying to build the last CMake from CVS on NetBSD.I checked out the source from CVS, and run the bootstrap scriptIt worked fine. ( I can provide the cmd output if needed )Then I run gmake, and I get some undefined references when trying to link ccmake in
libcmForm.a :Linking CXX executable
Brad King wrote:
I've now committed a new INSTALL framework which should solve this
problem among others. It isn't finished but the target installation
stuff is done. Now you should be able to do something like
INSTALL(TARGETS libchicken libuchicken RUNTIME DESTINATION "")
INSTALL(TARGETS
Brad King wrote:
In order to be consistent for both PREFIX and SUFFIX and allow them to
be set separately for the DLL and the import library, I created new
properties IMPORT_PREFIX and IMPORT_SUFFIX. I haven't updated the
documentation because these are part of incremental commits for a
lar
Brandon J. Van Every wrote:
Brad King wrote:
There are three problems here:
[snip]
3.) The .lib is mentioned even though it is not actually installed.
Furthermore, the .lib is mentioned even though it does not actually
*exist*. This is a MinGW build, there are no stub .libs by default.
I
Brandon J. Van Every wrote:
1.) The error message is worded poorly.
2.) The error is actually referring to the .dll, not the .lib and
is due to a bug with trailing slashes in the install destination.
3.) The .lib is mentioned even though it is not actually installed.
I've fixed #1 and #2 in
Brad King wrote:
1.) The error message is worded poorly.
2.) The error is actually referring to the .dll, not the .lib and
is due to a bug with trailing slashes in the install destination.
3.) The .lib is mentioned even though it is not actually installed.
I've fixed #1 and #2 in CVS which
Brad King wrote:
Brandon J. Van Every wrote:
which is the normal way that MinGW works. No stub .lib files. But
the install appears to be looking for .lib files:
[snip]
-- Installing E:/Program Files/Chicken/libchicken.lib
-- Installing E:/Program Files/Chicken//libchicken.dll
CMake Error: Er
Brandon J. Van Every wrote:
which is the normal way that MinGW works. No stub .lib files. But the
install appears to be looking for .lib files:
[snip]
-- Installing E:/Program Files/Chicken/libchicken.lib
-- Installing E:/Program Files/Chicken//libchicken.dll
CMake Error: Error in cmake code
Brandon J. Van Every wrote:
I note that on Cygwin and MinGW, there is no .lib component by default.
They just link to .dlls directly (and interop with MSVC generated dlls
isn't straightforward). So for those compiler targets, if I have a
target "whatever", and I say I want INSTALL_TARGETS(/ what
Brad King wrote:
Brandon J. Van Every wrote:
I'm using CMake CVS. My .dlls are being installed to
${CMAKE_INSTALL_PREFIX}/bin. Everything else is being installed to
${CMAKE_INSTALL_PREFIX} like I thought I told it to. Is this a bug
or a feature? It feels like a bug because of course things
Brandon J. Van Every wrote:
William A. Hoffman wrote:
Actually, I just tried it your way and it worked???
PROJECT(foo)
ADD_LIBRARY(libchicken foo.cxx)
SET_TARGET_PROPERTIES(libchicken PROPERTIES PREFIX "")
On my version, I now realize I called SET_TARGET_PROPERTIES before
calling ADD_LIBRAR
William A. Hoffman wrote:
Actually, I just tried it your way and it worked???
PROJECT(foo)
ADD_LIBRARY(libchicken foo.cxx)
SET_TARGET_PROPERTIES(libchicken PROPERTIES PREFIX "")
On my version, I now realize I called SET_TARGET_PROPERTIES before
calling ADD_LIBRARY. Is that an error?
I'm guess
Brandon J. Van Every wrote:
I'm using CMake CVS. My .dlls are being installed to
${CMAKE_INSTALL_PREFIX}/bin. Everything else is being installed to
${CMAKE_INSTALL_PREFIX} like I thought I told it to. Is this a bug or a
feature? It feels like a bug because of course things crash since the
At 08:29 AM 2/16/2006, William A. Hoffman wrote:
>At 02:53 AM 2/16/2006, Brandon J. Van Every wrote:
>>I notice that in CMake CVS, statements like
>>
>>SET(CHICKEN_LIB_NAME libchicken)
>>SET_TARGET_PROPERTIES(libchicken PROPERTIES PREFIX "")
>>
>>still don't work. I end up with things like liblibc
At 02:53 AM 2/16/2006, Brandon J. Van Every wrote:
>I notice that in CMake CVS, statements like
>
>SET(CHICKEN_LIB_NAME libchicken)
>SET_TARGET_PROPERTIES(libchicken PROPERTIES PREFIX "")
>
>still don't work. I end up with things like liblibchicken.a. That is too
>bad. I don't know if anyone in
I'm using CMake CVS. My .dlls are being installed to
${CMAKE_INSTALL_PREFIX}/bin. Everything else is being installed to
${CMAKE_INSTALL_PREFIX} like I thought I told it to. Is this a bug or a
feature? It feels like a bug because of course things crash since the
.dlls aren't in the right dir
I notice that in CMake CVS, statements like
SET(CHICKEN_LIB_NAME libchicken)
SET_TARGET_PROPERTIES(libchicken PROPERTIES PREFIX "")
still don't work. I end up with things like liblibchicken.a. That is
too bad. I don't know if anyone intended to work on this for CMake
2.3. It would make CMa
At 03:02 PM 2/15/2006, Brandon J. Van Every wrote:
>William A. Hoffman wrote:
>>That is expected behavior. SET(FOO a b c) is the same as SET(FOO a;b;c), it
>>sets FOO to a list of elements. SET(FOO "a b c") sets FOO to a single
>>element.
>>That being said, I am not exactly sure why we could no
William A. Hoffman wrote:
That is expected behavior. SET(FOO a b c) is the same as SET(FOO a;b;c), it
sets FOO to a list of elements. SET(FOO "a b c") sets FOO to a single element.
That being said, I am not exactly sure why we could not expand cmake lists
before
we write variables into makefi
At 01:58 PM 2/15/2006, you wrote:
>I'm using CMake CVS built with MinGW / MSYS. I have this in CMakeLists.txt.
>
>SET(SHARED_FLAGS -DC_NO_PIC_NO_DLL -DPIC)
>
>Then I do cmakesetup from the MSYS shell. I delete cache, configure, hit ok.
>"make -n chicken" reveals:
>
>e:/Dev-Cpp/bin/gcc.exe -DCB
I'm using CMake CVS built with MinGW / MSYS. I have this in CMakeLists.txt.
SET(SHARED_FLAGS -DC_NO_PIC_NO_DLL -DPIC)
Then I do cmakesetup from the MSYS shell. I delete cache, configure,
hit ok. "make -n chicken" reveals:
e:/Dev-Cpp/bin/gcc.exe -DCBUILDING_LIBCHICKEN -DC_NO_PIC_NO_DLL;-DP
> --- Ursprüngliche Nachricht ---
> Von: "Brandon J. Van Every" <[EMAIL PROTECTED]>
> An: cmake
> Betreff: [CMake] CMake CVS DEFINE_SYMBOL only works once
> Datum: Wed, 15 Feb 2006 00:59:44 -0800
>
> I've built CMake from CVS using MinGW / MSY
William A. Hoffman wrote:
OK, so here is the problem:
http://lists.trolltech.com/qt-interest/2006-01/thread00091-0.html
If make finds sh.exe in your path, it will use it, and then
"MinGW Makefiles" will not work. If sh.exe is in your PATH, then
you must use "MSYS Makefiles" or "Unix Makefiles"
I've built CMake from CVS using MinGW / MSYS. If I write code like the
following:
SET_TARGET_PROPERTIES(${CHICKEN_UNSAFE_LIB_NAME} PROPERTIES
DEFINE_SYMBOL C_BUILDING_LIBCHICKEN)
SET_TARGET_PROPERTIES(${CHICKEN_UNSAFE_LIB_NAME} PROPERTIES
DEFINE_SYMBOL C_UNSAFE_RUNTIME)
only the last symbol
At 09:41 PM 2/14/2006, William A. Hoffman wrote:
>OK, so here is the problem:
>
>http://lists.trolltech.com/qt-interest/2006-01/thread00091-0.html
>
>If make finds sh.exe in your path, it will use it, and then
>"MinGW Makefiles" will not work. If sh.exe is in your PATH, then
>you must use "MSYS Ma
OK, so here is the problem:
http://lists.trolltech.com/qt-interest/2006-01/thread00091-0.html
If make finds sh.exe in your path, it will use it, and then
"MinGW Makefiles" will not work. If sh.exe is in your PATH, then
you must use "MSYS Makefiles" or "Unix Makefiles". I suppose I could
put a
I've built CMake 2.3-20060213 from CVS using VS7.1. Installation looks
ok. I am now trying to build Chicken using MinGW / MSYS. After I
select "MinGW Makefiles" I get the following error:
The C compiler "e:/Dev-Cpp/bin/gcc.exe" is not able to compile a simple
test program.
It fails with th
I've compiled CMake 2.3-20060213 from CVS sources using MinGW and MSYS.
./bootstrap and make work fine. No build errors, and I seem to have
everything. When I do "make install," nothing is installed. At first I
thought it was that intermediate paths like /usr/local didn't exist, but
I creat
69 matches
Mail list logo
