Re: [CMake] ExternalProject and redundant update/configure/compile actions.

Agreed, but right now ExternalProject is my favorite solution to this problem. I prefer the ExternalProject approach over the ParaView + internal VTK / git-submodule approach. So I'm just looking for ways to alter ExternalProject to be a little nicer to my workflow, which is incremental builds of

Re: [CMake] ExternalProject and redundant update/configure/compile actions.

I think one issue is this: > 2. If the configure is re-run, it regenerates configuration files. For some projects, if you just update and run make, then nothing rebuilds and nothing reinstalls. But if you run cmake && make, then things rebuild and reinstall. So, maybe you *do* want to do an upd

Re: [CMake] ExternalProject and redundant update/configure/compile actions.

There's a related issue, I think, if you skip the update step, then the project never rebuilds, since reconfigure and rebuild depend on update. So if you modify a source file of a project without a download command, then superbuild will not rebuild the project. So my workaround (used in VES, for

[CMake] Incorrect setting of CUDA_HOST_COMPILER on macosx

Hi, FindCUDA.cmake sets CUDA_HOST_COMPILER to CMAKE_C_COMPILER. I think that the CUDA_HOST_COMPILER variable was introduced in cmake 2.8.10. The issue is that on macosx, CMAKE_C_COMPILER defaults to /usr/bin/cc which is clang, and clang is not a supported cuda compiler. One workaround is to set

Re: [CMake] Passing CMAKE_TOOLCHAIN_FILE on command line causes CMake warning

013 at 11:56 PM, David Cole wrote: > -Original Message- > From: Pat Marion > To: David Cole > Cc: themiwi ; cmake > Sent: Wed, Feb 6, 2013 8:34 am > Subject: Re: [CMake] Passing CMAKE_TOOLCHAIN_FILE on command line causes > CMake warning > > I'd li

Re: [CMake] Passing CMAKE_TOOLCHAIN_FILE on command line causes CMake warning

ot; because it's not a bug. > It's the intended behavior, and there are multiple ways to avoid the > legitimate warning. > > > Just my opinion, > D > > > > -Original Message- > From: Pat Marion > To: Michael Wild > Cc: cmake > Sent

Re: [CMake] Passing CMAKE_TOOLCHAIN_FILE on command line causes CMake warning

hange, or is there a reason the warning should remain? Pat On Wed, Feb 6, 2013 at 9:52 PM, Michael Wild wrote: > Hi > > > On Wed, Feb 6, 2013 at 11:59 AM, Pat Marion wrote: > >> Hi, >> >> I'm emailing about bug >> 13093<http://public.kitware.co

[CMake] Passing CMAKE_TOOLCHAIN_FILE on command line causes CMake warning

Hi, I'm emailing about bug 13093in the backlog. I found comments by Brad that suggest it's a legitimate warning, but I'm not sure how a project could avoid the warning. Maybe cmake cou

Re: [CMake] Building a tool to run on the host when cross-compiling

build > environments, sticking to make, and hoping it doesn't do anything strange > to your environment before calling the external project (because I don't > think I've seen this behaviour with make). > > Thanks, > Christopher > > > On Tue, Jan 22, 2013 at 3:

Re: [CMake] Building a tool to run on the host when cross-compiling

Hi Bill, We use ExternalProject on the VES project to manage crosscompile builds. We use ExternalProject to create builds for the host, Android, iOS-device, and iOS-simulator architectures. Pat On Fri, Jan 18, 2013 at 8:19 AM, Bill Hoffman wrote: > On 1/17/2013 5:01 PM, Christopher Lansing wrot

[CMake] ExternalProject danger- source directory is deleted

When using ExternalProject, sometimes the build rules decide that an existing source directory needs to be deleted and re{downloaded,cloned}. In my experience, this is pretty dangerous and I have lost work due to it. Would it be possible to throw an error and ask the user to perform the delete, or

Re: [CMake] [PATCH] bootstrap: Detect known C/C++ compiler toolchains

I tested it as Todd described on intrepid at Argonne, works. Pat On Sat, Jul 3, 2010 at 12:18 AM, Todd Gamblin wrote: > Brad, > > Sorry for the slow response. This patch works on dawndev (BG/P FEN) at > LLNL. I tested it with cmake 2.8.2, and just did bootstrap > --prefix=/path/to/install.

Re: [CMake] Platform file for Bluegene/P ?

The BlueGeneL platform file does indeed add '-lnss_files -lnss_dns -lresolv' to the link line. This should be removed on BlueGene/P. If you use the mpixlcxx wrapper then you don't need to add any extra libraries to the link line. If you want to invoke xlc directly without using the mpi wrapper s