Slightly improved version which treats "Linking" lines separately from
source lines.
and its not messed up by threaded builds.
---
#!/bin/bash
# filters CMake output to be more like nan-makefiles
FILTER="^\[ *[0-9]*%] \|^Built target "
make $@ | \
sed -u -e 's/^Linking .*\//Linkin
On 2010-12-20 21:08-0500 Clifford Yapp wrote:
If you are interested, I can send you a version of my FindTCL.cmake
once I get done reworking it to see if it would meet your needs.
Sure. I would be glad to help test your work for our particular
Tcl/Tk/itcl/itk needs.
Alan
_
Cool,
You might want to put a '^' after each \|, if that is how grep regex handles
it. I've tended toward egrep which is more perl like when doing more
complicated expressions. Color is probably lost since it is no longer a
tty.
Juan
On Mon, Dec 20, 2010 at 3:56 PM, Campbell Barton wrote:
> @
On Mon, Dec 20, 2010 at 8:23 PM, Alan W. Irwin
wrote:
> I agree that finding Tcl extensions such as Tk that are consistent
> with the version of Tcl that is found is important. We have run
> across this issue with the CMake-based PLplot build system and would
> welcome a solution.
So far I have
On 2010-12-20 18:27-0500 Clifford Yapp wrote:
[In] the case of Tcl/Tk I would prefer to move back from the splitting up
of Tcl/Tk functionality to just FindTCL.cmake - the primary reason for
this is to avoid situations where there are multiple Tcl/Tk systems
installed and the tclsh search return
On Mon, Dec 20, 2010 at 11:53 PM, Andreas Pakulat wrote:
> On 20.12.10 23:34:55, ny wrote:
> > The code was never been tested on a mac, not to mention snow leopard.
> > I have the guarantee that it compiles + builds for win + linux.
> > Project was a collaborative effort and unfortunately I am st
Hello all,
I'm using fixup_bundle as part of my installation rules. One problem
I've run into is that if you build the install target multiple times,
fixup_bundle (or, more specifically, copy_resolved_item_into_bundle)
won't copy a library over if it's coming from the same location. This
causes a
On Mon, Dec 20, 2010 at 11:54 PM, Ryan Pavlik wrote:
> It seems you might be "over-analyzing" the conversion: makefiles are much
> lower-level than well-written cmake build systems. I would suggest you
> start with the CMake tutorial [1], then start from scratch on the build
> system for this co
Looking at http://www.cmake.org/Wiki/CMake:Module_Maintainers (thanks
Brad for the link) it looks like my best option may be to actually
volunteer for the maintainership of FindX11, FindOpenGL and
FindTCL(sh/stubs/etc...), as they are not listed as being actively
maintained.
Since I need these mod
It seems you might be "over-analyzing" the conversion: makefiles are much
lower-level than well-written cmake build systems. I would suggest you
start with the CMake tutorial [1], then start from scratch on the build
system for this code. Think at a high level, about what files turn into
what exe
On 20.12.10 23:34:55, ny wrote:
> The code was never been tested on a mac, not to mention snow leopard.
> I have the guarantee that it compiles + builds for win + linux.
> Project was a collaborative effort and unfortunately I am stuck without a
> makefile =P and with the ugly *.vcproj file. Note t
greetings!
I am trying to build research code written in (templated) c++, size
is approximately ~15K lines.
The code was never been tested on a mac, not to mention snow leopard.
I have the guarantee that it compiles + builds for win + linux.
Project was a collaborative effort and unfortunately I
@Michael Wild. good point about threaded builds, so I take back the
bit about "Entering directory, then filenames only", nevertheless.
some way to reduce flooding the console when rebuilding a single file
would be much appreciated.
@Juan, from your suggestion, I now use this.
---
#!/bin/bash
# fi
The issue here is that XCode stores those command line arguments into the
same project file that CMake re-generates. I'm pretty sure there's an open
bug on this one, but it's a somewhat tricky issue. You might consider using
my CreateLaunchers cmake modules, available here [1] - while they don't
d
On 20 December 2010 16:07, Clinton Stimpson wrote:
> BundleUtilities already skips system libraries, so I don't see a difference
> between making a package and "make install" in this case.
> If you're using all system libraries, BundleUtilities can become a no-op.
You're basically saying "don't u
On 12/20/2010 03:34 PM, Alessandro Carpi wrote:
> Hi there,
>
> I am using cmake to generate Xcode projects starting from the usual
> CMakeLists.txt
>
> I often modify CMakeLists.txt to add some source, so I have to re-generate
> the whole project using cmake -G Xcode, but everytime I have to
>
Hi there,
I am using cmake to generate Xcode projects starting from the usual
CMakeLists.txt
I often modify CMakeLists.txt to add some source, so I have to re-generate
the whole project using cmake -G Xcode, but everytime I have to
manually set up the executable command line arguments from Xcode
On 12/16/2010 01:07 PM, Campbell Barton wrote:
> My question is why this is needed?
> set(CFLAG_TEST "CFLAG_TEST")
> CHECK_C_COMPILER_FLAG("${_FLAG}" CFLAG_TEST)
The CHECK_C_COMPILER_FLAG macro stores its result in the CMake cache so
that it persists across multiple runs in the same bu
On 20 December 2010 13:17, David Cole wrote:
> I don't think an INSTALL(... PACKAGE construct is necessary. And, in fact, I
> think it might be harmful. (For one thing, INSTALL(PACKAGE sounds like
> you're installing "a package", not like you're installing "something you've
> built but only as par
On Mon, Dec 20, 2010 at 7:51 AM, Mike McQuaid wrote:
> On 20 December 2010 12:34, David Cole wrote:
> > On Sun, Dec 19, 2010 at 3:50 PM, Mike McQuaid
> wrote:
> > When you find yourself in the "must escape too much" situation in an
> > INSTALL(CODE scenario you should switch to writing out
Hi,
I am trying to use the Symbian Carbide Generator from "
http://public.kitware.com/Bug/view.php?id=8486#c22281";
I have taken master branch and on top of it patches for symbian genrator
from Assaf at location
"
https://docs.google.com/uc?id=0BzHCK1hf14h2ZGFkNDE3MmEtNDc5MC00Njg5LTk4ZmItODVhNWF
On 20 December 2010 12:34, David Cole wrote:
> On Sun, Dec 19, 2010 at 3:50 PM, Mike McQuaid wrote:
> When you find yourself in the "must escape too much" situation in an
> INSTALL(CODE scenario you should switch to writing out a script that you
> then include with an INSTALL(SCRIPT command.
On Sun, Dec 19, 2010 at 3:50 PM, Mike McQuaid wrote:
> On 16 December 2010 08:34, Andreas Mohr wrote:
> > I'd like to know how to possibly detect this within CMake code.
>
> This works for me:
> INSTALL( CODE "
> IF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )
>
> ENDIF( \${CMA
> Greetings
>
> I tried an execute_process that spits out a file. Llets call this
> ${someDirectory}/someFile.
>
> I then tried to do a test like so
> if( ${someDirectory}/someFile 1 )
> --- do something
> endif( ${someDirectory}/someFile 1 )
>
> but it does not seem to work
>
> in shell sc
Greetings
I tried an execute_process that spits out a file. Llets call this
${someDirectory}/someFile.
I then tried to do a test like so
if( ${someDirectory}/someFile 1 )
--- do something
endif( ${someDirectory}/someFile 1 )
but it does not seem to work
in shell scripts{linux} we c
>>> On 19-12-2010 at 0:04, in message
, Todd Gamblin
wrote:
> Hey all,
>
> This has been brought up before (sort of) here:
>
>
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/26533
>
> FindMPI doesn't currently give you the libraries, includes, etc. for
> different lan
On 12/20/2010 01:01 AM, Campbell Barton wrote:
Hi, I'm STILL trying to have CMake makefiles replace Blender's hand
crafted makefiles.
Now the main sticking point with 2 other developers is they don't like
CMakes output, as its overly verbose.
I realize CMake doesn't need to bend to the whim of
27 matches
Mail list logo
