Re: [CMake] passing arguments to the final make

On 02/23/2012 12:04 AM, John Drescher wrote: >> And another thing, is it actually \${SCRIPT} a portable solution that works >> on all the generators? >> > > This is not about generators but about what shell you are running > cmake from. For example that would not work on windows since the > comman

Re: [CMake] delayed target

On 02/22/2012 11:55 PM, Andrea Crotti wrote: > On 02/22/2012 09:37 PM, Michael Hertling wrote: >> >> In order to define one target per egg, you'd need to know the eggs at >> configuration time since you cannot define targets at build time. So, >> gathering the eggs with a custom target/command will

Re: [CMake] lexical scoping ... back to the future !

Hi François, Would the use of function be helpful ? See http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:function and http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set "If PARENT_SCOPE is present, the variable will be set in the scope above the current scope. Each new di

[CMake] lexical scoping ... back to the future !

Hi CMakers, In november 2007, there was a long thread titled "lexical scoping". The discussion was really interesting and was suggesting that some "local scoping" features for variables could be implemented in CMake... particularly from macros, which are probably the practical case that causes m

Re: [CMake] CMake + Ninja

I was wondering if there was any plans to add the feature mentioned below? That said, a way of saying "build every target in this subdirectory" (for example, by specifying that subdirectory as a target on the command line) would be a nice feature to have. This would be very useful

Re: [CMake] passing arguments to the final make

> And another thing, is it actually \${SCRIPT} a portable solution that works > on all the generators? > This is not about generators but about what shell you are running cmake from. For example that would not work on windows since the command prompt has a different syntax for variables. John --

Re: [CMake] delayed target

On 02/22/2012 09:37 PM, Michael Hertling wrote: In order to define one target per egg, you'd need to know the eggs at configuration time since you cannot define targets at build time. So, gathering the eggs with a custom target/command will not work. As an alternative, you might gather the eggs

Re: [CMake] passing arguments to the final make

On 02/22/2012 09:18 PM, Michael Hertling wrote: On 02/22/2012 06:56 PM, Andrea Crotti wrote: On 02/22/2012 05:32 PM, Andrea Crotti wrote: Ah that's nice thanks, I'm not sure though that I can rely on being>= 2.8 always, and that's probably a requirement, right? I tried what you suggested and

Re: [CMake] Shared intermediary files

On 02/20/2012 10:07 PM, Kevin Schmidt wrote: > Hello, > I'm in the process of converting over a large, monolithic tree with many > libraries from a custom build solution over to cmake. So far, we've loved > it. I am wondering about others' solutions to a problem we have encountered. > > We h

Re: [CMake] delayed target

On 02/22/2012 07:21 PM, Andrea Crotti wrote: > On 02/22/2012 05:14 PM, Michael Hertling wrote: >> On 02/22/2012 05:02 PM, Andrea Crotti wrote: >>> Again I'm having some troubles with the different building stages: >>> >>> I would like to have a target that simply unzips all the files contained >>>

Re: [CMake] passing arguments to the final make

On 02/22/2012 06:56 PM, Andrea Crotti wrote: > On 02/22/2012 05:32 PM, Andrea Crotti wrote: >> >> Ah that's nice thanks, I'm not sure though that I can rely on being >= >> 2.8 always, >> and that's probably a requirement, right? >> > > I tried what you suggested and with this: > add_custom_target

[CMake] make a python script executable

So now suppose I have a working installer (which is not the case yet), and that the entry point of the whole program is a python script. Is there a way to make the whole project launchable via double click on more platforms? At the moment there is a run.bat in every project for this to run on

Re: [CMake] delayed target

On 02/22/2012 05:14 PM, Michael Hertling wrote: On 02/22/2012 05:02 PM, Andrea Crotti wrote: Again I'm having some troubles with the different building stages: I would like to have a target that simply unzips all the files contained in a directory, which can be found with a simple globbing.

Re: [CMake] passing arguments to the final make

On 02/22/2012 05:32 PM, Andrea Crotti wrote: Ah that's nice thanks, I'm not sure though that I can rely on being >= 2.8 always, and that's probably a requirement, right? I tried what you suggested and with this: add_custom_target(dev_no_run COMMAND ${PYTHON_EXECUTABLE} ${DEV_MAIN} -w ${WO

Re: [CMake] passing arguments to the final make

On 02/22/2012 06:32 PM, Andrea Crotti wrote: > On 02/22/2012 05:25 PM, Michael Hertling wrote: >> On 02/22/2012 04:43 PM, Andrea Crotti wrote: >>> I would like to be able to pass arguments to my generated Makefile. >>> >>> Suppose I use an environment variable like this: >>> >>> add_custom_target(r

Re: [CMake] passing arguments to the final make

On 02/22/2012 05:25 PM, Michael Hertling wrote: On 02/22/2012 04:43 PM, Andrea Crotti wrote: I would like to be able to pass arguments to my generated Makefile. Suppose I use an environment variable like this: add_custom_target(run_dev_script COMMAND ${PYTHON_EXECUTABLE} ${PREREQUISITE}

Re: [CMake] passing arguments to the final make

On 02/22/2012 04:43 PM, Andrea Crotti wrote: > I would like to be able to pass arguments to my generated Makefile. > > Suppose I use an environment variable like this: > > add_custom_target(run_dev_script >COMMAND ${PYTHON_EXECUTABLE} ${PREREQUISITE} >COMMAND ${PYTHON_EXECUTABLE} ${SCRIPT

Re: [CMake] CMAKE_INSTALL_LIBDIR - full path or relative?

Am Montag, 20. Februar 2012, 22:15:39 schrieb Michael Wild: > On 02/20/2012 09:59 PM, Orion Poplawski wrote: > > For quite a while, Fedora packages will call cmake with > > -DCMAKE_INSTALL_LIBDIR set to /usr/lib or /usr/lib64 as appropriate. > > Some projects that use this convention include plplot

Re: [CMake] delayed target

On 02/22/2012 05:02 PM, Andrea Crotti wrote: > Again I'm having some troubles with the different building stages: > > I would like to have a target that simply unzips all the files contained > in a directory, > which can be found with a simple globbing. > > add_custom_target(unzip_all_eggs >

[CMake] Suspecting major install ordering issue (causing BundleUtilities fixup_bundle() / verify_app() failure)

Hello all, in my project I'm doing the usual install( CODE " include(BundleUtilities) set(APPS ${APPS}) message(\"CALLING fixup_bundle on ${APPS}! fixup_bundle_libs ${fixup_bundle_libs}, DIRS ${DIRS}, DESTDIR is \$ENV{DESTDIR}\") fixup_bundle(\"\${APPS}\

[CMake] delayed target

Again I'm having some troubles with the different building stages: I would like to have a target that simply unzips all the files contained in a directory, which can be found with a simple globbing. add_custom_target(unzip_all_eggs file(GLOB eggs RELATIVE ${EGG_BUILD_DIRECTORY}/*egg) CO

Re: [CMake] checking arguments

On Wed, Feb 22, 2012 at 10:36 AM, Andrea Crotti wrote: > I find not so nice that CMake doesn't complain at all if some variables are > not defined. > Is there a way to make it complain if a variable used is actually blank? > > In the meanwhile I ended up with this: > > set(COMPULSORY_ARGUMENTS PSI

[CMake] passing arguments to the final make

I would like to be able to pass arguments to my generated Makefile. Suppose I use an environment variable like this: add_custom_target(run_dev_script COMMAND ${PYTHON_EXECUTABLE} ${PREREQUISITE} COMMAND ${PYTHON_EXECUTABLE} ${SCRIPT} ) Would that actually work? In theory ${SCRIPT} is subs

[CMake] checking arguments

I find not so nice that CMake doesn't complain at all if some variables are not defined. Is there a way to make it complain if a variable used is actually blank? In the meanwhile I ended up with this: set(COMPULSORY_ARGUMENTS PSI) set(OPTIONAL_ARGUMENTS WORKSPACE CONTAINER_PATHS) macro (check_

Re: [CMake] cpack issues

Alright then I now actually get an installer which I can click on, and cpack doesn't give any more errors. However, when I try to run the executable I get a "executable..exe The specified path does not exist.." which is quite a weird error, because it's the same path that I'm clicking, and it

[CMake] Announce: Kitware Holding CMake course April 2 in Lyon France

Kitware will be holding a developers training course on April 2, 2012 in Lyon, France. This 1-day course will cover CMake, CTest, CPack and CDash. Please visit our web site for more information and registration details (early registration ends March 19th!) at either: http://www.kitware.com/pr

Re: [CMake] Embarcadero C++ nightly test

On 23 February 2012 13:27, H Xu wrote: > The compiler could be downloaded from here: > http://www.embarcadero.com/products/cbuilder/downloads > > Although it says the trial is a 30-day trial, in fact, the command line tool > of the downloaded package, as far as I know, could be run for unlimited t

[CMake] Embarcadero C++ nightly test

Hello, In this ticket , it says "we'd like someone who has this compiler (Embarcadero C++) to run a nightly dashboard submission so we can keep it working. Otherwise it will not be officially supported." But why do not the official nightly te