Re: [CMake] multicore interix'en testing

Bill Hoffman wrote: > Markus Duft wrote: > >> btw, any chance to integrate this with buildbot? i have buildbot running >> already on the machines in question for our own sw, so it would be cool >> from a resource management POV. >> > No buildbot right now. If you want to contribute something

Re: [CMake] multicore interix'en testing

Alexander Neundorf wrote: > On Tuesday 23 February 2010, Markus Duft wrote: >> Bill Hoffman wrote: >>> I did not want to get into the technical thread on this issue, so I >>> created a new message. Markus, will you be able to run a dashboard for >>> this platform? It is sort of a requirement for

Re: [CMake] Adding a generated source to all multiple targets

Or this: http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_generate_a_source_file_during_the_build.3F On Wed, Feb 24, 2010 at 12:52 AM, Tyler Roscoe wrote: > On Tue, Feb 23, 2010 at 10:02:44PM -0600, Oliver Smith wrote: > > If I add "luapkg.cc" to the list of sources for any given target, CMake >

Re: [CMake] Adding a generated source to all multiple targets

On Tue, Feb 23, 2010 at 10:02:44PM -0600, Oliver Smith wrote: > If I add "luapkg.cc" to the list of sources for any given target, CMake > barfs because luapkg.cc doesn't exist. Does this help? http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_sf:GENERATED tyler __

[CMake] Adding a generated source to all multiple targets

I have a CMake project with a number of targets, and a Lua wrapper generated through tolua++ which is included by several of them, so that it is compiled with the target-specific make flags per-target. Global make flags: -O0 -ggdb3 -Wall -Werror ... etc Target1 make flags: -DAS_DB_PROXY ... Tar

Re: [CMake] how to find out the compiler ID of a compiler which doesn't link

On Monday 22 February 2010, Brad King wrote: > Alexander Neundorf wrote: > > Hi, > > > > it seems the IAR C/C++ compiler for AVR cannot generate executables, but > > only object files, and the linker has to be called explcitely on the > > generated object files: > > ftp://ftp.iar.se/WWWfiles/avr32/

Re: [CMake] multicore interix'en testing

Markus Duft wrote: btw, any chance to integrate this with buildbot? i have buildbot running already on the machines in question for our own sw, so it would be cool from a resource management POV. No buildbot right now. If you want to contribute something [3] mduft cmake-2.8.1-rc3 $ mak

Re: [CMake] multicore interix'en testing

On Tuesday 23 February 2010, Markus Duft wrote: > Bill Hoffman wrote: > > I did not want to get into the technical thread on this issue, so I > > created a new message. Markus, will you be able to run a dashboard for > > this platform? It is sort of a requirement for accepting patches like > > th

Re: [CMake] Support for languages without linking phase etc

On 23. Feb, 2010, at 15:13 , Ivan Chernetsky wrote: > 2010/2/22 Michael Wild : >> How about languages where there is no separate compiling phase, such as e.g. >> C#? Is there a placeholder in CMAKE__LINK_EXECUTABLE and >> CMAKE__CREATE_SHARED_LIBRARY that gets expanded to the list of source >>

[CMake] Trying to mix C++ and Fortran code...

I've just started using CMake and have great hopes for it making my life simpler. I currently have a windows console project that mixes C++ and Fortran code. I have the main body of the code (in Fortran), an interface to display code written in C++(in Fortran), and some display code (C++). I

Re: [CMake] Bug in Darwin CMAKE_SYSTEM_PROCESSOR

On 2/23/10 10:10 AM, Luis Kornblueh said: >for me it looks like a small bug in determining the processor type >in Darwin (MacOSX): > >uname -m returns always i386 despite of the processor used No, it can also return ppc or arm, depending. >uname -p returns on a laptop (Core2duo) running 10.5.x i

Re: [CMake] multicore interix'en testing

Bill Hoffman wrote: > Markus Duft wrote: >> Bill Hoffman wrote: >>> I did not want to get into the technical thread on this issue, so I >>> created a new message. Markus, will you be able to run a dashboard for >>> this platform? It is sort of a requirement for accepting patches like >>> this int

Re: [CMake] multicore interix'en testing

Bill Hoffman wrote: > Markus Duft wrote: >> Bill Hoffman wrote: >>> I did not want to get into the technical thread on this issue, so I >>> created a new message. Markus, will you be able to run a dashboard for >>> this platform? It is sort of a requirement for accepting patches like >>> this int

Re: [CMake] [PATCH] KWSys: Avoid buggy SIGCHLD on Interix

Markus Duft wrote: > the patch is ok as-is now. it fixes my issues on multi-core interix. Great. Thanks for testing. I'll include it in CMake upstream as soon as we have finished transitioning to the new Git repository I announced yesterday and open it for publishing. > in combination with my i

Re: [CMake] multicore interix'en testing

Markus Duft wrote: Bill Hoffman wrote: I did not want to get into the technical thread on this issue, so I created a new message. Markus, will you be able to run a dashboard for this platform? It is sort of a requirement for accepting patches like this into CMake. Otherwise, we are sure to br

Re: [CMake] Bug in Darwin CMAKE_SYSTEM_PROCESSOR

Luis Kornblueh wrote: Hi, for me it looks like a small bug in determining the processor type in Darwin (MacOSX): uname -m returns always i386 despite of the processor used uname -p returns on a laptop (Core2duo) running 10.5.x i386 (32bit kernel) uname -p returns on a MacPro (Nehalem)

Re: [CMake] [PATCH] KWSys: Avoid buggy SIGCHLD on Interix

Markus Duft wrote: > Brad King wrote: >> On Interix we cannot rely on SIGCHLD because it is only sometimes >> delivered. Our SIGCHLD handler wakes up any current select() call to >> check if its child terminated, but the handler itself does not care >> about any child. Therefore we can use the sa

Re: [CMake] multicore interix'en testing

Bill Hoffman wrote: > I did not want to get into the technical thread on this issue, so I > created a new message. Markus, will you be able to run a dashboard for > this platform? It is sort of a requirement for accepting patches like > this into CMake. Otherwise, we are sure to break things in

Re: [CMake] [PATCH] KWSys: Avoid buggy SIGCHLD on Interix

Brad King wrote: > On Interix we cannot rely on SIGCHLD because it is only sometimes > delivered. Our SIGCHLD handler wakes up any current select() call to > check if its child terminated, but the handler itself does not care > about any child. Therefore we can use the same handler with SIGALRM t

Re: [CMake] [vtkusers] cmake language syntax highlighting added to wiki

Could someone please point me to the configuration file for this mode ? I need to create a cmake syntax highlighting mode for docbook. Thanks On Wed, Jan 6, 2010 at 11:21 PM, David Doria wrote: > FYI anyone writing wiki pages - > > On the Kitware wiki's, you can now use: > > > ... cmake code he

[CMake] Bug in Darwin CMAKE_SYSTEM_PROCESSOR

Hi, for me it looks like a small bug in determining the processor type in Darwin (MacOSX): uname -m returns always i386 despite of the processor used uname -p returns on a laptop (Core2duo) running 10.5.x i386 (32bit kernel) uname -p returns on a MacPro (Nehalem) running 10.6.x x86_64

[CMake] Problem with flags under Windows/

Hi all, Currently I am using a CompilerFlags.cmake file for setting all my flags, done with: set(CMAKE_USER_MAKE_RULES_OVERRIDE ${CMAKE_CURRENT_SOURCE_DIR}/cmake/CompilerFlags.cmake CACHE STRING "Override makefile generation rules.") In this CompilerFlags.cmake all targets (DEBUG, RELEASE,...)