Re: [CMake] Execution order

2010-09-17 Thread Michael Wild
On 17. Sep, 2010, at 16:49 , David Aldrich wrote: > Hi Michael > >> Ok, to clear things up: > >> I hope you get the idea. > > Thanks very much, I think I get it now! I have implemented an out-of-source > build tree for our project, as you suggested, and it is building fine. Good. > > I'm

Re: [CMake] Execution order

2010-09-17 Thread David Aldrich
Hi Michael > Ok, to clear things up: > I hope you get the idea. Thanks very much, I think I get it now! I have implemented an out-of-source build tree for our project, as you suggested, and it is building fine. I'm wondering what my co-developers will think of it. It is usual for us to work

Re: [CMake] Execution order

2010-09-17 Thread Michael Wild
t; Cc: Chris Hillery; cmake@cmake.org > Subject: Re: [CMake] Execution order > > Your build system would be independent where the output files are: the user > can choose whatever build directory they want, and not be limited to > _gnuDebug and _gnuRelease. (If they so chose, they c

Re: [CMake] Execution order

2010-09-17 Thread David Aldrich
September 2010 13:07 To: David Aldrich Cc: Chris Hillery; cmake@cmake.org Subject: Re: [CMake] Execution order Your build system would be independent where the output files are: the user can choose whatever build directory they want, and not be limited to _gnuDebug and _gnuRelease. (If they so

Re: [CMake] Execution order

2010-09-17 Thread Ryan Pavlik
Your build system would be independent where the output files are: the user can choose whatever build directory they want, and not be limited to _gnuDebug and _gnuRelease. (If they so chose, they could create each of those and configure a build into them, but they are just as likely to not do so.

Re: [CMake] Execution order

2010-09-17 Thread David Aldrich
Hi Chris > No, you shouldn't have to, unless you're using in-source builds > which is very strongly deprecated. Once you've gotten used to > out-of-source builds you'll never want to go back. Ok, I'm trying to think of how this would work for us. The source for each of our libraries is in a s

Re: [CMake] Execution order

2010-09-17 Thread Chris Hillery
On Fri, Sep 17, 2010 at 3:22 AM, David Aldrich wrote: > Hi Chris > > > > Thanks for your reply. > > > > >The message() and file(REMOVE) commands will be executed when you run > CMake. > > >The command to generate the .cpp file won't be executed until you run > make. > > > > I don’t think I have ‘

Re: [CMake] Execution order

2010-09-17 Thread Michael Hertling
On 09/17/2010 12:04 PM, Chris Hillery wrote: > The message() and file(REMOVE) commands will be executed when you run CMake. > The command to generate the .cpp file won't be executed until you run make. > That's why it's still around after you're done. > > You can't really do exactly what you want

Re: [CMake] Execution order

2010-09-17 Thread David Aldrich
My only argument against it is that I will have to configure svn to ignore that source file. David From: c...@lambda.nu [mailto:c...@lambda.nu] On Behalf Of Chris Hillery Sent: 17 September 2010 11:05 To: David Aldrich Cc: cmake@cmake.org Subject: Re: [CMake] Execution order The message() and

Re: [CMake] Execution order

2010-09-17 Thread Chris Hillery
The message() and file(REMOVE) commands will be executed when you run CMake. The command to generate the .cpp file won't be executed until you run make. That's why it's still around after you're done. You can't really do exactly what you want here very easily; you'd need to have a separate custom

[CMake] Execution order

2010-09-17 Thread David Aldrich
Hi I want to generate a source file 'SourceFileInfo.cpp', then build a library and then delete the generated file. So I wrote: add_custom_command ( OUTPUT SourceFileInfo.cpp COMMAND ../VersionInfo/_gnuRelease/versionInfo . KERNEL DEPENDS ${SRCS} COMMENT "Generating SourceFileInfo.cpp"