CMake version 2.7-20080708
Mac OSX 10.5
XCode 3.0
I had to get the MACOSX_DEPLOYMENT_TARGET set correctly in the generated
XCode projects. I tried a lot but
could'nt find a solution so I had a look at the source and could'nt find
anything about CMAKE_OSX_DELPOYMENT_TARGET. It seemed to me lik
I downloaded a tarball of 2.6.1 and tried ./configure on one of the cray
test machines, it fails to compile cmake with the following
Linking C shared module libcmsysTestDynload.so
/opt/xt-asyncpe/1.0c/bin/cc: INFO: linux target is being used
/usr/bin/ld: /usr/lib64/libpthread.a(pt-system.o): rel
Bug number 6195 has been submitted for this. <
http://public.kitware.com/Bug/view.php?id=6195> I have most of the work
completed but still needs some testing and some tweaking. You can pull the
patches and apply them to your copy of CMake and rebuild if you want.
Mike Jackson
On Tue, Sep 23, 2008
Alan W. Irwin wrote:
Bill, can you or someone else from Kitware take over now to finish this
off?
If you don't have immediate access to Linux, I am willing to do any
experiments you suggest on that platform. Currently, I feel I am
floundering around close to the solution of the problem on my o
John Biddiscombe wrote:
I downloaded a tarball of 2.6.1 and tried ./configure on one of the cray
test machines, it fails to compile cmake with the following
Linking C shared module libcmsysTestDynload.so
/opt/xt-asyncpe/1.0c/bin/cc: INFO: linux target is being used
/usr/bin/ld: /usr/lib64/libpt
Bill
That is just a test. You might want to try make -k, most of cmake
does not require shared stuff. However, I don't think we have an
option to turn off all shared stuff yet.
Good spot. OK. cmake has built itself now. I should have realized that
the fail was on one of the tests. Bad th
John Biddiscombe wrote:
Bill
That is just a test. You might want to try make -k, most of cmake
does not require shared stuff. However, I don't think we have an
option to turn off all shared stuff yet.
Good spot. OK. cmake has built itself now. I should have realized that
the fail was on
Bill
You might want to move this over to the paraview developers list. I
know paraview was cross compiled onto a cray Xt3 machine, and there
are ways to build it without any shared stuff. See
http://vtk.org/Wiki/Cross_compiling_ParaView3_and_VTK
Yes indeed. mind you, it's because we're test
I have been using the Fortran dependency generator named makedepf90
(Erik Edelmann - 2.8.8) for years now. Recently, we have encountered a
bug in this application (infinite loop within the parser). I noticed
that Fortran dependencies are generated in cmake with the use of an
adaptation of makedep
Myers, Gary wrote:
I have been using the Fortran dependency generator named makedepf90
(Erik Edelmann - 2.8.8) for years now. Recently, we have encountered
a bug in this application (infinite loop within the parser). I
noticed that Fortran dependencies are generated in cmake with the use
of
Am Dienstag, 23. September 2008 schrieb Arjen Markus:
> I do not know what the changes in the code actually are, but one major
> problem was that using the
> word "use" in comments caused a false dependency. I do not know about
> infinite loops though.
>
> Regards,
>
> Arjen
This bug was in cmake-
Am Dienstag, 23. September 2008 schrieb Myers, Gary:
> I have been using the Fortran dependency generator named makedepf90
> (Erik Edelmann - 2.8.8) for years now. Recently, we have encountered a
> bug in this application (infinite loop within the parser). I noticed
> that Fortran dependencies ar
On Tuesday 23 September 2008 03:42:11 Philip Lowman wrote:
> Bill,
>
> Is a switch to Subversion still planned at some point in the near future
> for CMake?
Hopefully not.
>
> On occasion I have wanted to checkout the latest CVS from work and am
> reminded of the corporate firewall. =)
You want
On 23. Sep, 2008, at 17:10, Andreas Schneider wrote:
On Tuesday 23 September 2008 03:42:11 Philip Lowman wrote:
Bill,
Is a switch to Subversion still planned at some point in the near
future
for CMake?
Hopefully not.
On occasion I have wanted to checkout the latest CVS from work and a
Maik,
My work is performed on an isolated network. I will attempt to get a
test sample over, but it will take a little time.
I will also attempt to look up the infinite-loop (bug) reference to
makedepf90.
Regards,
-Gary
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTE
On Tuesday 23 September 2008 16:19:05 Michael Wild wrote:
> git rocks! ;-)
I agree but not everyone is happy using the console for their VCS. You move to
git and you alienate said people. Subversion, on the other hand, has a lots of
GUI tools available for such folks.
--
Cheers,
Mike Arthur
htt
Mike Arthur wrote:
On Tuesday 23 September 2008 16:19:05 Michael Wild wrote:
git rocks! ;-)
I agree but not everyone is happy using the console for their VCS. You move to
git and you alienate said people. Subversion, on the other hand, has a lots of
GUI tools available for such folks.
Lets n
On Tue, Sep 23, 2008 at 6:03 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> Mike Arthur wrote:
>>
>> On Tuesday 23 September 2008 16:19:05 Michael Wild wrote:
>>>
>>> git rocks! ;-)
>>
>> I agree but not everyone is happy using the console for their VCS. You
>> move to git and you alienate said peop
Mathieu Malaterre wrote:
svn 'external' links to repositories (not tested). Do not know what is
the default behavior for branching...
Yup, but there are issues with that. For one thing you can not do an
atomic commit from the top of the tree and have it go into the sub
project correctly.
On Tue, Sep 23, 2008 at 6:21 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> Mathieu Malaterre wrote:
>
>>
>> svn 'external' links to repositories (not tested). Do not know what is
>> the default behavior for branching...
>>
>
> Yup, but there are issues with that. For one thing you can not do an at
There was one other "bug" that I was seeing in the Qt Based cmake gui
client. The first time you click on the "configure" button and the
QDialog pops up asking for the type of project file to generate, this
dialog seems a lot larger than it really needs to be. Saw this on OS X
and Windows XP us
On Tuesday 23 September 2008 18:10:05 Mathieu Malaterre wrote:
> svn 'external' links to repositories (not tested). Do not know what is
> the default behavior for branching...
I'd stay away from svn:externals. We used those extensively in my company, and
they are a bother. E.g, branching doesn't
I guess I'm looking for a way to automatically "relay" information
between the main project B and one or more library projects A, etc. My
projects tend to involve lots of sub libraries, so I need a way for
this to work in a scalable manner.
If I try to simply INCLUDE A in B, then all the relative
I have a release candidate (RC 6) for 2.6.2 ready for CMake. There is
one small fix over RC 5. I fixed cpack so it would run from a symlink,
which fixes the command line install on Mac OSX when the application
bundle is used. If there are no issues by the morning I will do a
release tomorrow.
That is basically what I do. Until someone tells me a better way.
Take a look at the following link:
http://www.bluequartz.net/viewvc/CTMD/MXATools/CMakeLists.txt?view=markup
for an example of how I am doing things.
mike
Aleksander Demko wrote:
I guess I'm looking for a way to automaticall
. Original Message ...
On Tue, 23 Sep 2008 12:21:47 -0400 "Bill Hoffman" <[EMAIL PROTECTED]> wrote:
>Mathieu Malaterre wrote:
>
>>
>> svn 'external' links to repositories (not tested). Do not know what is
>> the default behavior for branching...
>>
>
>Yup, but there are issues with th
The only way would be something like this:
set(a "-mcpu=arm7tdmi -std=gnu99 -fgnu89-inline -finline-functions")
set(a "${a} -ffunction-sections -fdata-sections ")
set(a "${a} -fno-strict-aliasing -mno-thumb -Os -fomit-frame-pointer")
Ok thanks. Not really handy, but better than nothing ;-)
It
I think in the end I'll replace my ADD_SUBDIRECTORY+macros[1] method
for a simpler INCLUDE based ones. The INCLUDE based one isn't ideal
(and really, it seems like an abuse of INCLUDE for something
ADD_SUBDIRECTORY or EXPORT should do), but its less code and more
natural to cmake users.
Thanks for
Hi Manu,
On Tue, Sep 23, 2008 at 1:54 PM, Emmanuel Blot <[EMAIL PROTECTED]> wrote:
>> The only way would be something like this:
>>
>> set(a "-mcpu=arm7tdmi -std=gnu99 -fgnu89-inline -finline-functions")
>> set(a "${a} -ffunction-sections -fdata-sections ")
>> set(a "${a} -fno-strict-aliasing -mno
> Am Dienstag, 23. September 2008 schrieb Arjen Markus:
>> I do not know what the changes in the code actually are, but one major
>> problem was that using the
>> word "use" in comments caused a false dependency. I do not know about
>> infinite loops though.
>>
>> Regards,
>>
>> Arjen
>
> This bug
Hi,
I'm trying to build a build with cmake-2.6.1-win32-x86 CMakeSetup for
"Visual Studio 9 2008 Win64" as the build target.
Keep getting a
---
CMake Error: The source directory "./build/CMakeFiles/CMakeTmp" does not
exist.
Specify --help for usage, or press the help butto
Roger Martin wrote:
Hi,
I'm trying to build a build with cmake-2.6.1-win32-x86 CMakeSetup for
"Visual Studio 9 2008 Win64" as the build target.
Keep getting a
---
CMake Error: The source directory "./build/CMakeFiles/CMakeTmp" does not
exist.
Specify --help for usag
Given the fact that you know Bryan O'Sullivan, you should be
considering Mercurial.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Setting the full path fixes it. I'm wondering, on relative paths, if the
cmake home/bin directory is the root.
Yes, ./ is the current directory of the project from where I run a cmd
script.
With the paths fixed as you pointed out, I then get an error dialog with ...
The C compiler "
I also test with C:\OpenGL\cmake-2.6.1\Example\Hello which I believe foloows
the simple test case you described with c:\foo
And same result: cl.exe can't build a simple project.
On Tue, Sep 23, 2008 at 4:58 PM, Roger Martin <[EMAIL PROTECTED]>wrote:
> Setting the full path fixes it. I'm wonde
Roger Martin wrote:
Setting the full path fixes it. I'm wondering, on relative paths, if
the cmake home/bin directory is the root.
Yes, ./ is the current directory of the project from where I run a cmd
script.
With the paths fixed as you pointed out, I then get an error dialog
I suspect these questions will mostly give y'all your entertainment for the
day, but I freely admit my ignorance of things, so here goes.
Dependencies:
I'm working on porting existing code, so CMakeLists.txt already exists, and
I've made changes to it that allow me to compile. But I don't unders
"The environment is setup with a cmd called "run CMake.cmd" and attached
with the extension 'cmd' changed to 'ceemde'
"Where is the source code" =./ is assuming the directory from where I run
CMakeSetup as the working directory. Causes the error dialog
---
Error
--
Hi folks,
My apologies for cross-posting - I'm hoping this is of interest to the
ITK list, and it continues a month-old conversation on the CMake list.
Recap:
I like to have the debug and optimized versions of my ITK libraries
have different names (e.g. ITKCommon.lib, ITKCommond.lib). This way i
Thanks a lot, and list(REMOVE_ITEM ...) works well for me.
Another stupid question, as I am really new to c++. There are some cpp
files containing only inline functions and some template class
functions. The could not be compiled correctly as well, but if I
exclude them from compilation, errors wi
Roger Martin wrote:
The project consists entirely of configurations that require support for
platforms which are not installed on this machine. The project cannot be
loaded.
The project consists entirely of configurations that require support for
platforms which are not installed on
On Mon, Sep 22, 2008 at 4:35 AM, Gotthard, Petr <[EMAIL PROTECTED]
> wrote:
> I made a new bugtracker report. The FindRTI.cmake implementation is
> attached to it.
> http://public.kitware.com/Bug/view.php?id=7716
>
Petr,
I've added a couple of comments to the tracker report. Please realize I
do
That's it! Thank you for pin pointing the problem.
I then tried running CMakeSetup from the
C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\SetEnv.Cmd (Windows Server
2008 x64 DEBUG Build Environment) which outputs
Setting SDK environment relative to C:\Program Files\Microsoft
SDKs
Esben Mose Hansen wrote:
On Tuesday 23 September 2008 18:10:05 Mathieu Malaterre wrote:
svn 'external' links to repositories (not tested). Do not know what is
the default behavior for branching...
I'd stay away from svn:externals. We used those extensively in my company, and
they are a bothe
Dear Cmake users and developpers,
Our project builds fine with cmake and we can sucessfully generate
shared library( so files ) under Unix/Linux systems when using the
appropriate flag. However, when it comes to windows systems, visual
always build .lib files, even when activating the shared l
45 matches
Mail list logo
