Re: [CMake] continuous builds best practices?

[Bill Lorensen]

I use ctest scripts. Most itk and vtk dashboards are driven by ctest scripts.

Here is the one I use for a continuous Borland build. You need to
start it once a day. ctest will do the proper continuous checking of
the repository:
http://www.cdash.org/CDash/viewNotes.php?buildid=305082

Here is one for a linux build:

http://www.cdash.org/CDash/viewNotes.php?buildid=304831

Here is one for a Mac:

http://www.cdash.org/CDash/viewNotes.php?buildid=304789

To run a ctest script:

ctest -S scriptname

or for a verbose output:

ctest -V -S scriptname

Bill


On Thu, Apr 2, 2009 at 11:03 PM, Philip Lowman  wrote:
> On Thu, Apr 2, 2009 at 5:06 PM, Alexander Neundorf 
> wrote:
>>
>> On Wednesday 01 April 2009, Philip Lowman wrote:
>> > Is there a best practices for kicking off Continuous builds using ctest?
>> > What do most people do for this?
>> >
>> > I know about svn hooks but I don't want multiple builds spawned for each
>> > commit, just the latest commit when the machines are idle.  Also, I have
>> > multiple build machines on various operating systems.
>>
>> I think it's usually just "time triggered", e.g. every 15 minutes or so.
>
> Yeah I tried something like that and realized I would have to give up
> cleaning the build directory because it seems to recompile everytime, even
> if the svn revision number hasn't changed (bug?).  I don't use a config.h
> file so not rebuilding from scratch on every commit could potentially break
> the build on MSVC.
>
> I think I have a better idea which would be to turn ctest into a daemon that
> connects to a build server which sends out a per-branch pulse when a commit
> occurs.  Connected clients that are idle and interested in the pulse (by
> having already examined CVSROOT or svn info) could immediately start their
> builds.  Clients that are busy would queue their update & start their builds
> when the existing builds finish.
>
> ctest --daemon http://my.cdash.server.org/check.php \
>    -S foo-continuous-msvc80.cmake \
>    -S foo-continuous-msvc90.cmake
>
> In this way the continuous builds could be started nearly instantaneously
> after a commit.  Long polling could be used on the CDash server to make this
> work through proxy servers.  One could also envision CDash keeping tabs on
> connected sites and being able to inform the site administrator if one goes
> down in the middle of the day.
>
> --
> Philip Lowman
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] continuous builds best practices?

[Philip Lowman]

On Thu, Apr 2, 2009 at 5:06 PM, Alexander Neundorf
wrote:

> On Wednesday 01 April 2009, Philip Lowman wrote:
> > Is there a best practices for kicking off Continuous builds using ctest?
> > What do most people do for this?
> >
> > I know about svn hooks but I don't want multiple builds spawned for each
> > commit, just the latest commit when the machines are idle.  Also, I have
> > multiple build machines on various operating systems.
>
> I think it's usually just "time triggered", e.g. every 15 minutes or so.


Yeah I tried something like that and realized I would have to give up
cleaning the build directory because it seems to recompile everytime, even
if the svn revision number hasn't changed (bug?).  I don't use a config.h
file so not rebuilding from scratch on every commit could potentially break
the build on MSVC.

I think I have a better idea which would be to turn ctest into a daemon that
connects to a build server which sends out a per-branch pulse when a commit
occurs.  Connected clients that are idle and interested in the pulse (by
having already examined CVSROOT or svn info) could immediately start their
builds.  Clients that are busy would queue their update & start their builds
when the existing builds finish.

ctest --daemon http://my.cdash.server.org/check.php \
   -S foo-continuous-msvc80.cmake \
   -S foo-continuous-msvc90.cmake

In this way the continuous builds could be started nearly instantaneously
after a commit.  Long polling could be used on the CDash server to make this
work through proxy servers.  One could also envision CDash keeping tabs on
connected sites and being able to inform the site administrator if one goes
down in the middle of the day.

-- 
Philip Lowman
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] perennial question, how to setup environment for simple tests

[Philip Lowman]

On Thu, Apr 2, 2009 at 3:19 PM, Ian Monroe  wrote:

> I've seen this question in the archives, but I was wondering if
> there's been any progress since I last saw it asked (>1 year ago).
>
> I have some unit tests. I need to run a command or two and set some
> environmental variables before all the tests start. Does CMake have a
> solution for this yet? Are there any common practices to handle what
> I'm guessing is a pretty common thing?
>
> I notice that CTest would allow me to setup a test environment, but
> since it requires hardcoding the source and build directory it seems
> pretty inappropriate as a common-repo script used by multiple
> developers. Possibly the solution is to figure out how CTest can be
> used anyways.


This feature has been implemented in CMake CVS for some time thanks to David
Cole.  If someone would commit the patch I sent in so it shows up in the
documentation (attached to this bug) they could then close this bug.

http://public.kitware.com/Bug/view.php?id=7885

also this duplicate bug as well.
http://public.kitware.com/Bug/view.php?id=6391

-- 
Philip Lowman
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Need advice for unit test structure

[Michael Jackson]

On Apr 2, 2009, at 11:04 PM, Philip Lowman wrote:

On Thu, Apr 2, 2009 at 5:07 PM, Robert Dailey   
wrote:
If there was some way for CMake to utilize "solution folders" in  
Visual Studio, we could easily organize unit tests into a hierarchy.  
This way the solution explorer would not be cluttered and we'd still  
be able to have 1 project per unit test.


Never heard of unit tests that fail to compile before as a condition  
for success... I'm curious what kinds of things these could be used  
for?


Is there support for grouping projects in folders in Visual Studio?   
If not it could be added to VS.  If it is supported in VS you could  
send in a patch to make it work with CMake or at the very list  
request a feature.


Regarding the compile time tests, you could keep them separate but  
not enable them by default in your daily builds, just your nightly  
regression tests.


You could also make them "zzz_test_foo" compile time tests so they  
show up at the bottom of the list of projects where you'll never see  
them.  The PROJECT_LABEL target property should help with this.



--
Philip Lowman


Boost does that sort of thing, having a failed compile actually mean  
the test _passes_. I believe boost has a python script that drives the  
test. I think there was some traffic on the list last month about  
something in CTest where you could do a "compile-and-test" test.


   Hope that helps

Mike Jackson
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Need advice for unit test structure

[Philip Lowman]

On Thu, Apr 2, 2009 at 5:07 PM, Robert Dailey  wrote:

> If there was some way for CMake to utilize "solution folders" in Visual
> Studio, we could easily organize unit tests into a hierarchy. This way the
> solution explorer would not be cluttered and we'd still be able to have 1
> project per unit test.


Never heard of unit tests that fail to compile before as a condition for
success... I'm curious what kinds of things these could be used for?

Is there support for grouping projects in folders in Visual Studio?  If not
it could be added to VS.  If it is supported in VS you could send in a patch
to make it work with CMake or at the very list request a feature.

Regarding the compile time tests, you could keep them separate but not
enable them by default in your daily builds, just your nightly regression
tests.

You could also make them "zzz_test_foo" compile time tests so they show up
at the bottom of the list of projects where you'll never see them.  The
PROJECT_LABEL target property should help with this.


-- 
Philip Lowman
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Disabling RTTI in a portable way

[Robert Dailey]

Is there a portable way of disabling Runtime Type Information (RTTI) through
CMake? I hope I don't have to strangle CMake too much to get this basic
functionality...
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake could really use a debugger...

[Alexander Neundorf]

On Thursday 02 April 2009, Robert Dailey wrote:
> That's the thing that has the "Returning to" and "Entering" messages right?

No, it prints every cmake line which is executed.

Alex
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Output directory for generated ui_Header.h from Header.ui

[Alexander Neundorf]

On Thursday 02 April 2009, Ivan Chupahin wrote:
> Hi,folks!
>
> My project uses Qt4 and i need to generate *.h files from *.ui files. For
> that i use QT4_WRAP_UI macro. But it generete *.h files in a derectory
> where CMake is running. Maybe exit some CMake variable for point an output
> directory for that generated files or some other tools?

I think currently this cannot be changed.
Why do you want to change it ?

Alex
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] link_libraries() deprecated. Why?

[Alexander Neundorf]

On Thursday 02 April 2009, Brad King wrote:
> Alex,
>
> Looking at history I see this was deprecated by a patch you sent me.
> Originally we called the command 'discouraged'.  Why did we change
> to 'deprecated'?

I don't remember why we changed the wording.
The "deprecated" commands are commands which are in general not recommended 
anymore for use, but they are still available.
I.e. as a replacement for LINK_LIBRARIES() there is now 
TARGET_LINK_LIBRARIES() (since a long time already), which has advantages, 
and is in general recommended to be used instead, see below.

...
> > I don't like to use deprecated features, so I would love to see the
> > deprecation of link_libraries() to be reverted. But maybe I'm missing a
> > good reason for not doing so.
>
> Marcel, feel free to use link_libraries if there is no better solution.
> We do not plan to take it away.  The word 'deprecated' is too strong.
>
> One difference between link_libraries and include_directories is that
> library dependencies are chained automatically.  If you write

Alex
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] continuous builds best practices?

[Alexander Neundorf]

On Wednesday 01 April 2009, Philip Lowman wrote:
> Is there a best practices for kicking off Continuous builds using ctest?
> What do most people do for this?
>
> I know about svn hooks but I don't want multiple builds spawned for each
> commit, just the latest commit when the machines are idle.  Also, I have
> multiple build machines on various operating systems.

I think it's usually just "time triggered", e.g. every 15 minutes or so.

Alex
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Need advice for unit test structure

[Robert Dailey]

If there was some way for CMake to utilize "solution folders" in Visual
Studio, we could easily organize unit tests into a hierarchy. This way the
solution explorer would not be cluttered and we'd still be able to have 1
project per unit test.

On Thu, Apr 2, 2009 at 4:03 PM, Daniel Blezek wrote:

>  Hi Robert,
>
>   I don’t have any suggestions about the compile time unit tests, but we’ve
> been using the Google testing framework for the last 6 months and have been
> very happy with it.  I wrote up some details related to ITK here:
>
> http://www.itk.org/Wiki/Proposals:Increasing_ITK_Code_Coverage#Google_Test
>
> You can have multiple tests embedded in one executable, which is what the
> gtest framework does.
>
> Best regards,
> -dan
>
>
> On 4/2/09 3:00 PM, "Robert Dailey"  wrote:
>
> Hi,
>
> Currently we have a directory called "test" under each project we have.
> Each source file (CPP) results in 1 unit test project being created. So if
> we have a project named "foobar", it would be structured like this on the
> filesystem:
>
> foobar/test/test1.cpp
> foobar/test/test2.cpp
> foobar/test/test3.cpp
>
> And the generated visual studio projects (when created via CMake) would be:
>
> foobar
> foobar_test1
> foobar_test2
> foobar_test3
>
> Obviously this creates a lot of clutter in the solution explorer window in
> Visual Studio. Is there a more recommended practice for structuring unit
> tests in CMake? Personal advice is also welcome. One approach I'd like to
> take is where we only have two projects:
>
> foobar
> foobar_test
>
> And inside foobar_test, all of the sources under the /test/ directory would
> be included, so a single project compiles all unit tests.
>
> foobar_test
>   test1.cpp
>   test2.cpp
>   test3.cpp
>
> However, the reason why I'm currently not doing this is because of
> compile-time unit testing. Basically, some unit tests are designed to be
> successful if they fail to compile. For example, perhaps certain template
> parameters do not meet the requirements of a specific C++ concept, and thus
> rightfully fail. This unit test would be considered successful because we
> want to make sure that ONLY types matching this specific concept are
> accepted by the compiler.
>
> If we include these source files in the same project, then it interrupts
> the whole compilation process. They have to be separate in order to work
> properly.
>
> --
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
>
> --
> *Daniel Blezek, PhD
> *Medical Imaging Informatics Innovation Center
>
> P 127 or (77) 8 8886
> T 507 538 8886
> E blezek.dan...@mayo.edu
>
> Mayo Clinic
> 200 First St. S.W.
> Harwick SL-44
> Rochester, MN 55905
> mayoclinic.org
>
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to pass values up to parent CMakeLists.txt

[Alexander Neundorf]

On Wednesday 01 April 2009, James Bigler wrote:
...
> You can also look into define/get/set_property, but I've never used those.

Yes, I'd suggest a GLOBAL property for this. It's IMO the cleanest way to do 
it.

Alex
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Need advice for unit test structure

[Daniel Blezek]

Hi Robert,

  I don¹t have any suggestions about the compile time unit tests, but we¹ve
been using the Google testing framework for the last 6 months and have been
very happy with it.  I wrote up some details related to ITK here:

http://www.itk.org/Wiki/Proposals:Increasing_ITK_Code_Coverage#Google_Test

You can have multiple tests embedded in one executable, which is what the
gtest framework does.

Best regards,
-dan 


On 4/2/09 3:00 PM, "Robert Dailey"  wrote:

> Hi,
> 
> Currently we have a directory called "test" under each project we have. Each
> source file (CPP) results in 1 unit test project being created. So if we have
> a project named "foobar", it would be structured like this on the filesystem:
> 
> foobar/test/test1.cpp
> foobar/test/test2.cpp
> foobar/test/test3.cpp
> 
> And the generated visual studio projects (when created via CMake) would be:
> 
> foobar
> foobar_test1
> foobar_test2
> foobar_test3
> 
> Obviously this creates a lot of clutter in the solution explorer window in
> Visual Studio. Is there a more recommended practice for structuring unit tests
> in CMake? Personal advice is also welcome. One approach I'd like to take is
> where we only have two projects:
> 
> foobar
> foobar_test
> 
> And inside foobar_test, all of the sources under the /test/ directory would be
> included, so a single project compiles all unit tests.
> 
> foobar_test
>   test1.cpp
>   test2.cpp
>   test3.cpp
> 
> However, the reason why I'm currently not doing this is because of
> compile-time unit testing. Basically, some unit tests are designed to be
> successful if they fail to compile. For example, perhaps certain template
> parameters do not meet the requirements of a specific C++ concept, and thus
> rightfully fail. This unit test would be considered successful because we want
> to make sure that ONLY types matching this specific concept are accepted by
> the compiler.
> 
> If we include these source files in the same project, then it interrupts the
> whole compilation process. They have to be separate in order to work properly.
> 
> 
> ___
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake

-- 
Daniel Blezek, PhD
Medical Imaging Informatics Innovation Center

P 127 or (77) 8 8886
T 507 538 8886
E blezek.dan...@mayo.edu

Mayo Clinic
200 First St. S.W.
Harwick SL-44
Rochester, MN 55905
mayoclinic.org


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake could really use a debugger...

[Robert Dailey]

haha, good one. I replied on an impulse. I didn't even think about googling
it :)
Thanks for the link ;)

On Thu, Apr 2, 2009 at 2:55 PM, Sean McBride wrote:

> On 4/2/09 2:49 PM, Robert Dailey said:
>
> >What is GDB?
>
> Sorry, can't resist:
> 
>
> --
> 
> Sean McBride, B. Eng s...@rogue-research.com
> Rogue Researchwww.rogue-research.com
> Mac Software Developer  Montréal, Québec, Canada
>
>
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Need advice for unit test structure

[Robert Dailey]

Hi,
Currently we have a directory called "test" under each project we have. Each
source file (CPP) results in 1 unit test project being created. So if we
have a project named "foobar", it would be structured like this on the
filesystem:

foobar/test/test1.cpp
foobar/test/test2.cpp
foobar/test/test3.cpp

And the generated visual studio projects (when created via CMake) would be:

foobar
foobar_test1
foobar_test2
foobar_test3

Obviously this creates a lot of clutter in the solution explorer window in
Visual Studio. Is there a more recommended practice for structuring unit
tests in CMake? Personal advice is also welcome. One approach I'd like to
take is where we only have two projects:

foobar
foobar_test

And inside foobar_test, all of the sources under the /test/ directory would
be included, so a single project compiles all unit tests.

foobar_test
  test1.cpp
  test2.cpp
  test3.cpp

However, the reason why I'm currently not doing this is because of
compile-time unit testing. Basically, some unit tests are designed to be
successful if they fail to compile. For example, perhaps certain template
parameters do not meet the requirements of a specific C++ concept, and thus
rightfully fail. This unit test would be considered successful because we
want to make sure that ONLY types matching this specific concept are
accepted by the compiler.

If we include these source files in the same project, then it interrupts the
whole compilation process. They have to be separate in order to work
properly.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake could really use a debugger...

[Sean McBride]

On 4/2/09 2:49 PM, Robert Dailey said:

>What is GDB?

Sorry, can't resist:


-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake could really use a debugger...

[Robert Dailey]

On Thu, Apr 2, 2009 at 1:38 PM, Jed Brown  wrote:

> On Thu 2009-04-02 13:17, Robert Dailey wrote:
> > It would be great to see CMake provide some more debug-related commands
> later.
> > Perhaps CMake could even implement its own prompt.
>
> It would be extremely useful to be able to set watchpoints and
> breakpoints.  Basically the GDB commands break, watch, display, print,
> continue, next, step, finish, set, enable, disable, backtrace, and set
> var=.  Of course, it's your IDE's responsibility to hook into this if
> you want a GUI.


What is GDB?
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] perennial question, how to setup environment for simple tests

[Ian Monroe]

I've seen this question in the archives, but I was wondering if
there's been any progress since I last saw it asked (>1 year ago).

I have some unit tests. I need to run a command or two and set some
environmental variables before all the tests start. Does CMake have a
solution for this yet? Are there any common practices to handle what
I'm guessing is a pretty common thing?

I notice that CTest would allow me to setup a test environment, but
since it requires hardcoding the source and build directory it seems
pretty inappropriate as a common-repo script used by multiple
developers. Possibly the solution is to figure out how CTest can be
used anyways.

Thanks,
Ian Monroe
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake could really use a debugger...

[Jed Brown]

On Thu 2009-04-02 13:17, Robert Dailey wrote:
> It would be great to see CMake provide some more debug-related commands later.
> Perhaps CMake could even implement its own prompt.

It would be extremely useful to be able to set watchpoints and
breakpoints.  Basically the GDB commands break, watch, display, print,
continue, next, step, finish, set, enable, disable, backtrace, and set
var=.  Of course, it's your IDE's responsibility to hook into this if
you want a GUI.

Jed


pgptO1hdSy7lr.pgp
Description: PGP signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake could really use a debugger...

[Robert Dailey]

Good idea, but this requires domain knowledge.
For someone completely unfamiliar with the CMake code-base, this would be
impractical. However I still appreciate the thought!

It would be great to see CMake provide some more debug-related commands
later. Perhaps CMake could even implement its own prompt. For example:

Assume we have a CMakeLists.txt file with the following contents:
project( foo )
set( fubar "something arbitrary" )
add_executable( foo main.cpp )

And we would debug this file using the CMake debugger prompt like follows:

*C:\>cmake --debug-prompt*
*> step-forward*
*line 1: project( foo )*
*> view-variable "fubar"*
*Variable "fubar" not found*
*> step-forward*
*line 2: set( fubar "something arbitrary" )*
*> view-variable "fubar"*
*fubar ==> "something arbitrary"*
*> step-forward*
*line 3: add_executable( foo main.cpp )*

Later on, third party tools could be created to work directly with the
prompt and make usable frontends for people who prefer a GUI solution to
debugging like Visual Studio.


On Thu, Apr 2, 2009 at 12:57 PM, James Bigler  wrote:

> On Thu, Apr 2, 2009 at 11:51 AM, Robert Dailey  wrote:
>
>> That's the thing that has the "Returning to" and "Entering" messages
>> right?
>> If it is, that's somewhat helpful but not anywhere near what I'm asking
>> for. Think of how visual studio debugs C++ code. That's exactly the most
>> optimal debugging method I would like to see for CMake. Here's a couple of
>> abilities/features I expect:
>>
>>- The ability to view the values of variables dynamically. In other
>>words, as I step through code and the variable's value changes, I want to
>>see the values change in real-time, just like Visual Studio's Watch 
>> window.
>>- I want to be able to pause at each line of CMake code as it is
>>executing to evaluate the state of the application. I should be able to
>>press a key (like F10) in whatever debugger I'm using to progress to the
>>next line.
>>
>> I'm guessing such a thing does not exist. In addition, if CMake.exe does
>> not provide a way to step through the code and view variable values
>> dynamically, no such tool can be made for it. CMake has to support the
>> required hooks.
>>
>> On Thu, Apr 2, 2009 at 11:42 AM, Bill Hoffman 
>> wrote:
>>
>>> Robert Dailey wrote:
>>>
 I can't tell you how hard it is to hunt down strange behavior in CMake.
 Often times I would save myself 30 minutes of time on each of the hard bug
 fixes if I could just step through each line of logic as it was being
 executed and view the values of variables in a "watch" window of some sort.

 Does anyone know if such a CMake debugger exists? If not, are there
 plans to make one officially by the CMake team or some third party?


  Have you tried: cmake --trace
>>>
>>> -Bill
>>>
>>
> What about using a debug version of CMake and firing up the VS debugger?
> By putting break points in the right places in cmake.exe you might be able
> to query the state of things as CMake sees it.
>
> It might be too extreme for what you are asking for, but you could try it
> in 30 minutes rather than waiting for support for this feature.
>
> James
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Core dump after "- Check for working C compiler" on OS400 ( i5/OS PowerPC 32bit) with 2.6.2

[Ulf Wendel]

Bill Hoffman schrieb:

Can you run cmake in a debugger?


It did not tell me much. Maybe because the custom compiled one lacked 
debug info. I did not follow up on this. From what I guessed based on 
"grepping" through the source it could be something super simple that is 
causing the exception, something like pushing an empty string onto a 
std::string vector.


I could not imagine that CMake would have such a simple bug and therefore...

(dbx) where
raise(??) at 0xd006c13c
abort() at 0xd009a3ac
unnamed block in _ZN9__gnu_cxx27__verbose_terminate_handlerEv(), line 97 
in "vterminate.cc"
unnamed block in _ZN9__gnu_cxx27__verbose_terminate_handlerEv(), line 97 
in "vterminate.cc"
unnamed block in _ZN9__gnu_cxx27__verbose_terminate_handlerEv(), line 97 
in "vterminate.cc"
unnamed block in _ZN9__gnu_cxx27__verbose_terminate_handlerEv(), line 97 
in "vterminate.cc"

_ZN9__gnu_cxx27__verbose_terminate_handlerEv(), line 97 in "vterminate.cc"
_ZN10__cxxabiv111__terminateEPFvvE(??), line 43 in "eh_terminate.cc"
_ZSt9terminatev(), line 53 in "eh_terminate.cc"
unnamed block in 
_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecb(??, 
??, ??), line 77 in "locale-inst.cc"
unnamed block in 
_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecb(??, 
??, ??), line 77 in "locale-inst.cc"
unnamed block in 
_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecb(??, 
??, ??), line 77 in "locale-inst.cc"
unnamed block in 
_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecb(??, 
??, ??), line 77 in "locale-inst.cc"
unnamed block in 
_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecb(??, 
??, ??), line 77 in "locale-inst.cc"
unnamed block in 
_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecb(??, 
??, ??), line 77 in "locale-inst.cc"
_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecb(??, 
??, ??), line 77 in "locale-inst.cc"

_ZSt19__throw_logic_errorPKc(??), line 63 in "functexcept.cc"
unnamed block in _ZNSt13runtime_errorD0Ev(??, ??, ??, ??), line 528 in 
"stdexcept.cc"
unnamed block in _ZNSt13runtime_errorD0Ev(??, ??, ??, ??), line 528 in 
"stdexcept.cc"
unnamed block in _ZNSt13runtime_errorD0Ev(??, ??, ??, ??), line 528 in 
"stdexcept.cc"

_ZNSt13runtime_errorD0Ev(??, ??, ??, ??), line 528 in "stdexcept.cc"
_ZNSt11logic_errorC2ERKSs(??, ??, ??), line 1449 in "stdexcept.cc"
_ZN17cmGlobalGenerator10TryCompileEPKcS1_S1_S1_PSsP10cmMakefile(0x20109f80, 
0x2012780c, 0x2012780c, 0x107878f4, 0x10787908, 0x2ff21608, 0x2010b860) 
at 0x10270d8c
_ZN10cmMakefile10TryCompileEPKcS1_S1_S1_PKSt6vectorISsSaISsEEPSs(0x2010b860, 
0x2012780c, 0x2012780c, 0x107878f4, 0x10787908, 0x2ff215e4, 0x2ff21608) 
at 0x1018d26c
_ZN16cmCoreTryCompile14TryCompileCodeERKSt6vectorISsSaISsEE(0x20126020, 
0x2ff217ec) at 0x10107278
_ZN19cmTryCompileCommand11InitialPassERKSt6vectorISsSaISsEER17cmExecutionStatus(0x20126020, 
0x2ff217ec, 0x2ff219b4) at 0x1010840c
_ZN9cmCommand17InvokeInitialPassERKSt6vectorI18cmListFileArgumentSaIS1_EER17cmExecutionStatus(0x20126020, 
0x2012609c, 0x2ff219b4) at 0x10093864
_ZN10cmMakefile14ExecuteCommandERK18cmListFileFunctionR17cmExecutionStatus(0x2010b860, 
0x20126090, 0x2ff219b4) at 0x101a1314
_ZN19cmIfFunctionBlocker17IsFunctionBlockedERK18cmListFileFunctionR10cmMakefileR17cmExecutionStatus(0x20112140, 
0x201274a8, 0x2010b860, 0x2ff21c84) at 0x100dd068
_ZN10cmMakefile17IsFunctionBlockedERK18cmListFileFunctionR17cmExecutionStatus(0x2010b860, 
0x201274a8, 0x2ff21c84) at 0x10131da0
_ZN10cmMakefile14ExecuteCommandERK18cmListFileFunctionR17cmExecutionStatus(0x2010b860, 
0x201274a8, 0x2ff21c84) at 0x101a0e94
_ZN10cmMakefile12ReadListFileEPKcS1_PSs(0x2010b860, 0x0, 0x2011284c, 
0x0) at 0x101a2104
_ZN17cmGlobalGenerator14EnableLanguageERKSt6vectorISsSaISsEEP10cmMakefileb(0x20109f80, 
0x2ff21fb0, 0x2010b860, 0x10e2ec) at 0x10277748
_ZN30cmGlobalUnixMakefileGenerator314EnableLanguageERKSt6vectorISsSaISsEEP10cmMakefileb(0x20109f80, 
0x2ff21fb0, 0x2010b860, 0x10db70) at 0x10429bb0
_ZN10cmMakefile14EnableLanguageERKSt6vectorISsSaISsEEb(0x2010b860, 
0x2ff21fb0, 0x112cbc) at 0x1018e2a4
_ZN16cmProjectCommand11InitialPassERKSt6vectorISsSaISsEER17cmExecutionStatus(0x2010db40, 
0x2ff2203c, 0x2ff2227c) at 0x100c1dfc
_ZN9cmCommand17InvokeInitialPassERKSt6vectorI18cmListFileArgumentSaIS1_EER17cmExecutionStatus(0x2010db40, 
0x2011798c, 0x2ff2227c) at 0x10093864
_ZN10cmMakefile14ExecuteCommandERK18cmListFileFunctionR17cmExecutionStatus(0x2010b860, 
0x20117980, 0x2ff2227c) at 0x101a1314
_ZN10cmMakefile12ReadListFileEPKcS1_PSs(0x2010b860, 0x2010d83c, 0x0, 
0x0) at 0x101a2104

_ZN16cmLocalGenerator9ConfigureEv(0x2010b6e0) at 0x102a5190
_ZN29cmLocalUnixMakefileGenerator39ConfigureEv(0x2010b6e0) at 0x1045e840
_ZN17cmGlobalGenerator9ConfigureEv(0x20109f80) at 0x10273d3c
_ZN5cmake15ActualConfigureEv(0x2ff22878) at 0x1038

Re: [CMake] CMake could really use a debugger...

[James Bigler]

On Thu, Apr 2, 2009 at 11:51 AM, Robert Dailey  wrote:

> That's the thing that has the "Returning to" and "Entering" messages right?
> If it is, that's somewhat helpful but not anywhere near what I'm asking
> for. Think of how visual studio debugs C++ code. That's exactly the most
> optimal debugging method I would like to see for CMake. Here's a couple of
> abilities/features I expect:
>
>- The ability to view the values of variables dynamically. In other
>words, as I step through code and the variable's value changes, I want to
>see the values change in real-time, just like Visual Studio's Watch window.
>- I want to be able to pause at each line of CMake code as it is
>executing to evaluate the state of the application. I should be able to
>press a key (like F10) in whatever debugger I'm using to progress to the
>next line.
>
> I'm guessing such a thing does not exist. In addition, if CMake.exe does
> not provide a way to step through the code and view variable values
> dynamically, no such tool can be made for it. CMake has to support the
> required hooks.
>
> On Thu, Apr 2, 2009 at 11:42 AM, Bill Hoffman wrote:
>
>> Robert Dailey wrote:
>>
>>> I can't tell you how hard it is to hunt down strange behavior in CMake.
>>> Often times I would save myself 30 minutes of time on each of the hard bug
>>> fixes if I could just step through each line of logic as it was being
>>> executed and view the values of variables in a "watch" window of some sort.
>>>
>>> Does anyone know if such a CMake debugger exists? If not, are there plans
>>> to make one officially by the CMake team or some third party?
>>>
>>>
>>>  Have you tried: cmake --trace
>>
>> -Bill
>>
>
What about using a debug version of CMake and firing up the VS debugger?  By
putting break points in the right places in cmake.exe you might be able to
query the state of things as CMake sees it.

It might be too extreme for what you are asking for, but you could try it in
30 minutes rather than waiting for support for this feature.

James
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake could really use a debugger...

[Robert Dailey]

That's the thing that has the "Returning to" and "Entering" messages right?
If it is, that's somewhat helpful but not anywhere near what I'm asking for.
Think of how visual studio debugs C++ code. That's exactly the most optimal
debugging method I would like to see for CMake. Here's a couple of
abilities/features I expect:

   - The ability to view the values of variables dynamically. In other
   words, as I step through code and the variable's value changes, I want to
   see the values change in real-time, just like Visual Studio's Watch window.
   - I want to be able to pause at each line of CMake code as it is
   executing to evaluate the state of the application. I should be able to
   press a key (like F10) in whatever debugger I'm using to progress to the
   next line.

I'm guessing such a thing does not exist. In addition, if CMake.exe does not
provide a way to step through the code and view variable values dynamically,
no such tool can be made for it. CMake has to support the required hooks.

On Thu, Apr 2, 2009 at 11:42 AM, Bill Hoffman wrote:

> Robert Dailey wrote:
>
>> I can't tell you how hard it is to hunt down strange behavior in CMake.
>> Often times I would save myself 30 minutes of time on each of the hard bug
>> fixes if I could just step through each line of logic as it was being
>> executed and view the values of variables in a "watch" window of some sort.
>>
>> Does anyone know if such a CMake debugger exists? If not, are there plans
>> to make one officially by the CMake team or some third party?
>>
>>
>>  Have you tried: cmake --trace
>
> -Bill
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] incrementally adding source file properties

[Tobias Rudolph]

On 2 Apr 2009, at 19:12, Bill O'Hara wrote:

Is it possible to incrementally add new properties to source files?  
In two parts of a large build there are cases where it'd be very  
convenient to be able to do this:


set_source_file_properties(foo.c PROPERTIES COMPILE_FLAGS "-m32")
set_source_file_properties(foo.c PROPERTIES COMPILE_FLAGS "-g")

and have the properties be "-m32 -g". Right now it seems to instead  
just set it to "-g" and there seems not to be a way to read the  
properties and use the existing value as part of a new string?


There isn't always a place to definitively set the properties so its  
not an option right now to build up the options in a separate  
variable and just do the set_source_file_properties once.


thanks
b.


Just use "set_property( SOURCE ..." - it has an APPEND option which  
will do the trick.


--tobias
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] incrementally adding source file properties

[Eric Noulard]

2009/4/2 Eric Noulard :
> 2009/4/2 Bill O'Hara :
>> Is it possible to incrementally add new properties to source files? In two
>> parts of a large build there are cases where it'd be very convenient to be
>> able to do this:
>>
>> set_source_file_properties(foo.c PROPERTIES COMPILE_FLAGS "-m32")
>>
>> set_source_file_properties(foo.c PROPERTIES COMPILE_FLAGS "-g")
>>
>> and have the properties be "-m32 -g". Right now it seems to instead just set
>> it to "-g" and there seems not to be a way to read the properties and use
>> the existing value as part of a new string?
>
> What about
> get_source_file_property(OLD_FLAGS foo.c COMPILE_FLAGS)

You should check that do not get "NOTFOUND" because the COMPILE_FLAGS
property is not [yet] defined on the specified file.

> set_source_file_properties(foo.c PROPERTIES COMPILE_FLAGS "${OLD_FLAGS} -g") ?
>
> Should be possible to implement a
>
> update_source_file_properties(...)
>
> which does the job.
>
>
>
> --
> Erk
>



-- 
Erk
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] incrementally adding source file properties

[Eric Noulard]

2009/4/2 Bill O'Hara :
> Is it possible to incrementally add new properties to source files? In two
> parts of a large build there are cases where it'd be very convenient to be
> able to do this:
>
> set_source_file_properties(foo.c PROPERTIES COMPILE_FLAGS "-m32")
>
> set_source_file_properties(foo.c PROPERTIES COMPILE_FLAGS "-g")
>
> and have the properties be "-m32 -g". Right now it seems to instead just set
> it to "-g" and there seems not to be a way to read the properties and use
> the existing value as part of a new string?

What about
get_source_file_property(OLD_FLAGS foo.c COMPILE_FLAGS)
set_source_file_properties(foo.c PROPERTIES COMPILE_FLAGS "${OLD_FLAGS} -g") ?

Should be possible to implement a

update_source_file_properties(...)

which does the job.



-- 
Erk
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] incrementally adding source file properties

[Bill O'Hara]

Is it possible to incrementally add new properties to source files? In two
parts of a large build there are cases where it'd be very convenient to be
able to do this:

set_source_file_properties(foo.c PROPERTIES COMPILE_FLAGS "-m32")

set_source_file_properties(foo.c PROPERTIES COMPILE_FLAGS "-g")


and have the properties be "-m32 -g". Right now it seems to instead just set
it to "-g" and there seems not to be a way to read the properties and use
the existing value as part of a new string?


There isn't always a place to definitively set the properties so its not an
option right now to build up the options in a separate variable and just do
the set_source_file_properties once.


thanks

b.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake could really use a debugger...

[Bill Hoffman]

Robert Dailey wrote:
I can't tell you how hard it is to hunt down strange behavior in CMake. 
Often times I would save myself 30 minutes of time on each of the hard 
bug fixes if I could just step through each line of logic as it was 
being executed and view the values of variables in a "watch" window of 
some sort.


Does anyone know if such a CMake debugger exists? If not, are there 
plans to make one officially by the CMake team or some third party?




Have you tried: cmake --trace

-Bill
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Win32: Find location of VS redistributable runtime files ?

[Marcus D. Hanwell]

James Bigler wrote:
> On Thu, Apr 2, 2009 at 7:49 AM, Stephen Collyer
> mailto:scoll...@netspinner.co.uk>> wrote:
>
>
> 2009/4/2 Philip Lowman mailto:phi...@yhbt.com>>
>
> On Thu, Apr 2, 2009 at 7:00 AM, Stephen Collyer
> mailto:scoll...@netspinner.co.uk>>
> wrote:
>
> In the course of installation, I want to copy the
> redistributable C++ runtime libs
> directory from VS into my deliverable package. However,
> this should work with
> both VS8 and VS9. Could someone tell me how I can detect
> the build environment
> and locate the appropriate directory to do this ? For
> example, if building with
> VS9 I want to locate the directory:
>
> C:\Program Files\Microsoft Visual Studio
> 9.0\VC\redist\x86\Microsoft.VC90.CRT
>
> I'm guessing that there's a CMAKE_* variable that allow me
> to do this,
> but I'm not sure which.
>
>
> You can include InstallRequiredSystemFiles for this. See:
> 
> http://www.cmake.org/cmake/help/cmake2.6docs.html#module:InstallRequiredSystemLibraries
>
> VS9 support was added to this script and I believe it was
> first added in CMake 2.6.0
>
> -- 
> Philip Lowman
>
>
>
> Thanks for that - I'd completely forgotten about the existence of
> that module.
>
> I've tried it and I have one question though - it seems to dump
> the manifest and
> DLLs into the bin directory - it was my understanding that these
> had to go into
> a subdirectory of bin called Microsoft.VC80.CRT. Am I misinformed ?
>
>
>  
> I just recently shipped something with the redistributables, and it
> worked just fine putting them next to the dll (i.e. bin directory).
>
I worked on the packaging for Avogadro on Windows using VS. It works
very well with the files in the bin directory and as I understand
Windows, it looks in the same directory as the binary and then the path
is searched.

One issue we had was with plugins that were not in the binary directory.
I solved that by disabling the generation of manifests for modules in
our build scripts. I still need to clean up our Windows build as the way
we copy external libraries such as Qt is pretty hackish right now, but
that works too using a similar approach.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CMake could really use a debugger...

[Robert Dailey]

I can't tell you how hard it is to hunt down strange behavior in CMake.
Often times I would save myself 30 minutes of time on each of the hard bug
fixes if I could just step through each line of logic as it was being
executed and view the values of variables in a "watch" window of some sort.
Does anyone know if such a CMake debugger exists? If not, are there plans to
make one officially by the CMake team or some third party?
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Win32: Find location of VS redistributable runtime files ?

[James Bigler]

On Thu, Apr 2, 2009 at 7:49 AM, Stephen Collyer
wrote:

>
> 2009/4/2 Philip Lowman 
>
> On Thu, Apr 2, 2009 at 7:00 AM, Stephen Collyer > > wrote:
>>
>>> In the course of installation, I want to copy the redistributable C++
>>> runtime libs
>>> directory from VS into my deliverable package. However, this should work
>>> with
>>> both VS8 and VS9. Could someone tell me how I can detect the build
>>> environment
>>> and locate the appropriate directory to do this ? For example, if
>>> building with
>>> VS9 I want to locate the directory:
>>>
>>> C:\Program Files\Microsoft Visual Studio
>>> 9.0\VC\redist\x86\Microsoft.VC90.CRT
>>>
>>> I'm guessing that there's a CMAKE_* variable that allow me to do this,
>>> but I'm not sure which.
>>
>>
>> You can include InstallRequiredSystemFiles for this. See:
>>
>> http://www.cmake.org/cmake/help/cmake2.6docs.html#module:InstallRequiredSystemLibraries
>>
>> VS9 support was added to this script and I believe it was first added in
>> CMake 2.6.0
>>
>> --
>> Philip Lowman
>>
>
>
> Thanks for that - I'd completely forgotten about the existence of that
> module.
>
> I've tried it and I have one question though - it seems to dump the
> manifest and
> DLLs into the bin directory - it was my understanding that these had to go
> into
> a subdirectory of bin called Microsoft.VC80.CRT. Am I misinformed ?



I just recently shipped something with the redistributables, and it worked
just fine putting them next to the dll (i.e. bin directory).

James
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cpack and PackageMaker

[Bill Hoffman]

Benne, Kyle wrote:

Hello CMake Users,

 

Quick question.  Does CPack support pre and post flight scripts with the 
PackageMaker generator?




Yes, it does, CMake uses this for installing the command line tools.

SET(CPACK_POSTFLIGHT_SCRIPT "@CMAKE_POSTFLIGHT_SCRIPT@")
SET(CPACK_POSTUPGRADE_SCRIPT "@CMAKE_POSTUPGRADE_SCRIPT@")

-Bill

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cpack and PackageMaker

[Benne, Kyle]

Hello CMake Users,

 

Quick question.  Does CPack support pre and post flight scripts with the
PackageMaker generator? 

 

Regards,

 

Kyle 

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Core dump after "- Check for working C compiler" on OS400 ( i5/OS PowerPC 32bit) with 2.6.2

[Ulf Wendel]

Bill Hoffman schrieb:

Ulf Wendel wrote:

Hi,

CMake 2.6.2 gives me a crash on OS/400 (i5/OS PowerPC 32bit):

-- The C compiler identification is VisualAge
-- The CXX compiler identification is VisualAge
-- Check for working C compiler: /QOpenSys/vac600/usr/vacpp/bin/xlc_r
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct NULL not valid
/bin/bash: line 44: 2871447 IOT/Abort trap  (core dumped) 
/home/mysqldev/bs/connector-common-32bit/inst/cmake/bin/cmake -G "Unix 
Makefiles" -DCONNECTOR_PLATFORM=i5pase-powerpc-32bit 
-DMYSQL_CONFIG_EXECUTABLE="/home/mysqldev/bs/connector-common-32bit/inst/mysql-server-gpl-static/bin/mysql_config" 
-DMYSQLCPPCONN_TRACE_ENABLE:BOOL=1
#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#= 



Can you run cmake in a debugger?


I can try, I'll have to learn how... :-)
Just in case anybody is bored and wants the core dump...


Did you build CMake yourself, or is it a Kitware build?


I have compiled it myself.

Thanks,
Ulf

--
Ulf Wendel, MySQL
Sun Microsystems GmbH,   Sonnenallee 1,   D-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Win32: Find location of VS redistributable runtime files ?

[Stephen Collyer]

2009/4/2 Philip Lowman 

> On Thu, Apr 2, 2009 at 7:00 AM, Stephen Collyer  > wrote:
>
>> In the course of installation, I want to copy the redistributable C++
>> runtime libs
>> directory from VS into my deliverable package. However, this should work
>> with
>> both VS8 and VS9. Could someone tell me how I can detect the build
>> environment
>> and locate the appropriate directory to do this ? For example, if building
>> with
>> VS9 I want to locate the directory:
>>
>> C:\Program Files\Microsoft Visual Studio
>> 9.0\VC\redist\x86\Microsoft.VC90.CRT
>>
>> I'm guessing that there's a CMAKE_* variable that allow me to do this,
>> but I'm not sure which.
>
>
> You can include InstallRequiredSystemFiles for this. See:
>
> http://www.cmake.org/cmake/help/cmake2.6docs.html#module:InstallRequiredSystemLibraries
>
> VS9 support was added to this script and I believe it was first added in
> CMake 2.6.0
>
> --
> Philip Lowman
>


Thanks for that - I'd completely forgotten about the existence of that
module.

I've tried it and I have one question though - it seems to dump the manifest
and
DLLs into the bin directory - it was my understanding that these had to go
into
a subdirectory of bin called Microsoft.VC80.CRT. Am I misinformed ?

If it works, it's very convenient though.

--
Stephen Collyer
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] autoheader

[BRM]

Thanks for the clarifications.

Perhaps my err in this discussion is by referencing the Find functions too 
generally, and early on too specifically...

Philip Lowman wrote:
1. Just because you call find_package() on a package doesn't mean that
you need a preprocessor definition in your code in order to use it. 
The same is true of checking to see if a function or header file exists
(perhaps just to throw an error if it doesn't).
It is very often these days that one intends merely to build a plugin
by using a 3rd party package in which case adding a global #define via
a config.h file is not wanted at all.

I think that is not really an issue as the modules that do not need to do so 
simply would do so. This would, of course, have to be done on a 
module-by-module basis, so the module specific find functions would be the only 
ones that would be able to make that kind of call. The highly generic functions 
would have difficulty there.


Philip Lowman wrote:
There is no guarantee that the find module will pick the proper preprocessor
definitions to define if a package is present.  The reason why is that
these vary from project to project.
...

 I think that's the strongest argument against it; but then, wouldn't this be 
resolved by the package specific find functions (E.g. FindQt4)?
And those functions would just have to worry about changes between versions, 
which _should_ be (but won't necessarily be) few and far between, no?

So to be clear - the highly generic functions would not necessarily be of use 
to supporting an autoheader style function internally; but the project specific 
functions would be able to make good use of it with little to no issue.

Philip Lowman wrote:
It would seem that laying the responsibility of calling
cmake_autoheader() on the find module would limit you to one config.h
header file without really complicating the API.

Again, look at the examples I provided. The user's call to generate the 
autoheader could be done multiple times for multiple files while the internals 
to add the variables operated more globally so that any single variable was not 
added to only one list - but all them. The filtering method (including add and 
remove) was provided so a user could limit what they got from the list _if_ 
they chose to, and per someone's suggestion (see list archives).

So again, I think this is a non-issue.

Philip Lowman wrote:
So basically, it might not always be right and it might not always be
wanted.  Not to mention the work involved in retrofitting the find
modules so that they #define the "proper" stuff.

Isn't it easier to do so once for a single project (e.g. cmake as a whole) 
versus every programmer that wants to use the functionality to have to retrofit 
their CMakeLists.txt for every little package they want to have autoheader 
support for? Someone is going to have to retrofit at some point. So why not do 
it in the most reusable way that minimizes cross-project differences and 
promotes the most re-use and platform stability?

Philip Lowman wrote:
Perhaps find_package(), check_library_exists(), etc. could be augmented to 
optionally support the autoheader api?

I think that makes the good sense.

Philip Lowman wrote:
Regardless of whether or not this happens, as Bill pointed out a user
could always use a wrapper function themselves where it makes sense to.
function(find_package_add_define _pkg)
   find_package(${_pkg} ${ARGN})
   cmake_autodefine(... HAVE_${_pkg})  # or what-have-you
endfunction()

I think this should be the project designer's _last_ resort for adding a 
package; or at the worst a stepping stone while they are waiting on support 
from CMake provided functions.

Though where users have to, perhaps we could speed things up by providing an 
easy way for them to provide those functions to CMake for others to benefit 
from - it'd help generate a series of a project specific functions for it, and 
alleviate/speed up the work for CMake devs. I'm sure you already have something 
in place this way for the various CMake script functions, and this wouldn't 
really be any different - just updating existing ones and adding new ones. The 
library would grow.

(Summary) So basically - the autoheader stuff for find functions should more or 
less be only supported by module specific functions - not module independent 
functions, and we should encourage users (though not require) to send in new 
support functions or patches for existing functions that don't support it 
already.

Ben___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] link_libraries() deprecated. Why?

[Brad King]

Alex,

Looking at history I see this was deprecated by a patch you sent me.
Originally we called the command 'discouraged'.  Why did we change
to 'deprecated'?

Marcel Loose wrote:

Thanks for your reply. Your solution is ok, but it looks a bit like a
workaround for a feature that is missing, but was once there:
link_libraries().

To me, it's not really clear why link_libraries() has been deprecated
and, for example, include_directories() has not. IMHO, using
target_link_libraries() for a general library has a too fine
granularity. 
Suppose include_directories() were deprecated as well in favour of, say,

target_include_directories(). That would create the same problem: carry
around variables holding a bunch of include directories that must be
supplied to each target.

I don't like to use deprecated features, so I would love to see the
deprecation of link_libraries() to be reverted. But maybe I'm missing a
good reason for not doing so.


Marcel, feel free to use link_libraries if there is no better solution.
We do not plan to take it away.  The word 'deprecated' is too strong.

One difference between link_libraries and include_directories is that
library dependencies are chained automatically.  If you write

  add_library(mylib mylib.c)
  target_link_libraries(mylib m)
  add_executable(myexe myexe.c)
  target_link_libraries(myexe mylib)

then 'myexe' will link to both 'mylib' and 'm' (-lmylib -lm).
If you write

  link_libraries(m)
  add_library(mylib mylib.c)
  add_executable(myexe myexe.c)
  target_link_libraries(myexe mylib)

then 'myexe' will link 'm', 'mylib', and then 'm' again (-lm -lmylib -lm).
The reason is that the add_executable line copies the current set of
directory-level libraries from link_libraries when it is created.  Any
target_link_libraries after that are appended.  A strict rule our link
line generator follows is that the original link line for a target is
preserved, so for 'myexe' it starts with 'm' and 'mylib'.  Then it sees
that 'mylib' depends on 'm' and appends the library to the final link line.

If your project has a hierarchy of libraries already, just use
target_link_libraries to add the globally required library to the
top-most libraries in the hierarchy.  Link dependency analysis will
take care of the rest.

-Brad


On Wed, 2009-04-01 at 23:50 -0400, Philip Lowman wrote:

On Wed, Apr 1, 2009 at 5:35 PM, Marcel Loose  wrote:
Hi all,

I was wondering why the link_libraries() command has been

deprecated. Commands like include_directories() and
link_directories() which have the same "scope" have not been
deprecated. I think that link_libraries() has its virtues too.

My reason for asking this, is that I wonder what's the proper

way to add a library to *all* targets in a project; for
example, a logging library or a threads library. Here,
link_libraries() provides IMHO a much cleaner solution, than
target_link_libraries(). The latter requires me to keep track
of the globally used library in a variable that must be passed
around; and for each target I must explicitly specify its
dependency on this library by using target_link_libraries().

Or, am I missing something, and is there a cleaner way to do

this, without using a deprecated feature?

Often I have seen people write functions to help with this especially
if you have more than one common library.

function(link_target_against_common_libs _target)
   target_link_libraries(${_target} ${WHATEVER_LIBRARY})
endfunction()

Another approach is if you have a low level library as part of your
codebase that everyone depends upon you can simply make it dependent
on your threading or logging libraries and anyone that is dependent
against it will automatically link against the threading or logging
library.


--
Philip Lowman


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Core dump after "- Check for working C compiler" on OS400 ( i5/OS PowerPC 32bit) with 2.6.2

[Bill Hoffman]

Ulf Wendel wrote:

Hi,

CMake 2.6.2 gives me a crash on OS/400 (i5/OS PowerPC 32bit):

-- The C compiler identification is VisualAge
-- The CXX compiler identification is VisualAge
-- Check for working C compiler: /QOpenSys/vac600/usr/vacpp/bin/xlc_r
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct NULL not valid
/bin/bash: line 44: 2871447 IOT/Abort trap  (core dumped) 
/home/mysqldev/bs/connector-common-32bit/inst/cmake/bin/cmake -G "Unix 
Makefiles" -DCONNECTOR_PLATFORM=i5pase-powerpc-32bit 
-DMYSQL_CONFIG_EXECUTABLE="/home/mysqldev/bs/connector-common-32bit/inst/mysql-server-gpl-static/bin/mysql_config" 
-DMYSQLCPPCONN_TRACE_ENABLE:BOOL=1
#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#= 



Can you run cmake in a debugger?

Did you build CMake yourself, or is it a Kitware build?

-Bill
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Core dump after "- Check for working C compiler" on OS400 ( i5/OS PowerPC 32bit) with 2.6.2

[Ulf Wendel]

Hi,

CMake 2.6.2 gives me a crash on OS/400 (i5/OS PowerPC 32bit):

-- The C compiler identification is VisualAge
-- The CXX compiler identification is VisualAge
-- Check for working C compiler: /QOpenSys/vac600/usr/vacpp/bin/xlc_r
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct NULL not valid
/bin/bash: line 44: 2871447 IOT/Abort trap  (core dumped) 
/home/mysqldev/bs/connector-common-32bit/inst/cmake/bin/cmake -G "Unix 
Makefiles" -DCONNECTOR_PLATFORM=i5pase-powerpc-32bit 
-DMYSQL_CONFIG_EXECUTABLE="/home/mysqldev/bs/connector-common-32bit/inst/mysql-server-gpl-static/bin/mysql_config" 
-DMYSQLCPPCONN_TRACE_ENABLE:BOOL=1

#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=
ERROR[con-cpp][i5os-ppc32]: Got error code 134 from:

I think CMake is done with the C compiler check and getting the crash 
when checking for the C++ compiler. Please find CMakeOutput.log nad 
CMakeSystem.cmake below. The C++ compiler is VisualAge C++ Professional 
/ C for AIX Compiler, Version 6.


Any hints?

Thanks,
Ulf


$ cat CMakeOutput.log

The system is: OS400 - 4 - powerpc
Compiling the C compiler identification source file "CMakeCCompilerId.c" 
succeeded.

Compiler: /QOpenSys/vac600/usr/vacpp/bin/xlc_r
Build flags: 
-O2;-g;-ma;-qstrict;-qoptimize=2;-qmaxmem=8192;-qlanglvl=extended

Id flags:

The output was:
0


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
produced "a.out"


The C compiler identification is VisualAge, found in 
"/home/mysqldev/bs/connector-c++-32bit/src/mysql-connector-c++-563/CMakeFiles/CompilerIdC/a.out"


Compiling the CXX compiler identification source file 
"CMakeCXXCompilerId.cpp" succeeded.

Compiler: /QOpenSys/vac600/usr/vacpp/bin/xlC_r
Build flags: -O2;-g;-ma;-qstrict;-qoptimize=2;-qmaxmem=8192
Id flags:

The output was:
0


Compilation of the CXX compiler identification source 
"CMakeCXXCompilerId.cpp" produced "a.out"


The CXX compiler identification is VisualAge, found in 
"/home/mysqldev/bs/connector-c++-32bit/src/mysql-connector-c++-563/CMakeFiles/CompilerIdCXX/a.out"



$ cat CMakeSystem.cmake


SET(CMAKE_SYSTEM "OS400-4")
SET(CMAKE_SYSTEM_NAME "OS400")
SET(CMAKE_SYSTEM_VERSION "4")
SET(CMAKE_SYSTEM_PROCESSOR "powerpc")

SET(CMAKE_HOST_SYSTEM "OS400-4")
SET(CMAKE_HOST_SYSTEM_NAME "OS400")
SET(CMAKE_HOST_SYSTEM_VERSION "4")
SET(CMAKE_HOST_SYSTEM_PROCESSOR "powerpc")

SET(CMAKE_CROSSCOMPILING "FALSE")

SET(CMAKE_SYSTEM_LOADED 1)

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Win32: Find location of VS redistributable runtime files ?

[Philip Lowman]

On Thu, Apr 2, 2009 at 7:00 AM, Stephen Collyer
wrote:

> In the course of installation, I want to copy the redistributable C++
> runtime libs
> directory from VS into my deliverable package. However, this should work
> with
> both VS8 and VS9. Could someone tell me how I can detect the build
> environment
> and locate the appropriate directory to do this ? For example, if building
> with
> VS9 I want to locate the directory:
>
> C:\Program Files\Microsoft Visual Studio
> 9.0\VC\redist\x86\Microsoft.VC90.CRT
>
> I'm guessing that there's a CMAKE_* variable that allow me to do this,
> but I'm not sure which.


You can include InstallRequiredSystemFiles for this. See:
http://www.cmake.org/cmake/help/cmake2.6docs.html#module:InstallRequiredSystemLibraries

VS9 support was added to this script and I believe it was first added in
CMake 2.6.0

-- 
Philip Lowman
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] link_libraries() deprecated. Why?

[Philip Lowman]

On Thu, Apr 2, 2009 at 4:03 AM, Marcel Loose  wrote:

> Hi Philip,
>
> Thanks for your reply. Your solution is ok, but it looks a bit like a
> workaround for a feature that is missing, but was once there:
> link_libraries().
>
> To me, it's not really clear why link_libraries() has been deprecated
> and, for example, include_directories() has not. IMHO, using
> target_link_libraries() for a general library has a too fine
> granularity.
> Suppose include_directories() were deprecated as well in favour of, say,
> target_include_directories(). That would create the same problem: carry
> around variables holding a bunch of include directories that must be
> supplied to each target.
>
> I don't like to use deprecated features, so I would love to see the
> deprecation of link_libraries() to be reverted. But maybe I'm missing a
> good reason for not doing so.


I'm not sure why the feature was "deprecated".  I didn't even know about it
until you posted the question!  I also don't know exactly what CMake's
stance is on deprecation although I think the official policy is not to
remove old commands because it would break backwards compatibility.  The
word "deprecated" can imply that the feature is meant to be removed but
doesn't necessarily mean so.  The ambiguity there really sucks.  Perhaps
"obsolete" is a better choice of words.

-- 
Philip Lowman
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Output directory for genereated ui_Header.h files

[Alexandre Feblot]

Hi,

 

I wrote this macro to generate my ui.[ch] and moc files in my source
directory. Use it as a QT4_WRAP_UI replacement.

The macro also creates a "ui" target which generates all these files.

(Note: I use it with Qt 3, and did not check if uic is used the same way
on Qt 4.

 

 

#---


# ui (in) : name of the list containing ui files

# headers (in+out): name of the list containing

# - in : user headers containing Q_OBJECT macro

# - out: in value + headers generated from ui files

# sources (out)   : name of the list containing generated c++ files

#---


macro(k_gen_qt_code ui headers sources)

set_directory_properties(PROPERTIES CLEAN_NO_CUSTOM true) # don't
remove installed includes on make clean

  set(dest ${CMAKE_CURRENT_SOURCE_DIR})

foreach(ui_name ${${ui}})

string(REGEX REPLACE "ui$" "h" header ${ui_name})

string(REGEX REPLACE "ui$" "cxx" source ${ui_name})

 

add_custom_command(

  OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/${header}

WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}

  COMMAND ${QT_UIC} ${ui_name} -o ${header}

  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${ui_name}

  COMMENT "Generating
${CMAKE_CURRENT_SOURCE_DIR}/${header}"

 )

set (${headers} ${${headers}} ${header})

 

add_custom_command(

  OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/${source}

WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}

  COMMAND ${QT_UIC} ${ui_name} -impl ${header} -o
${source}

  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${ui_name}

  COMMENT "Generating
${CMAKE_CURRENT_SOURCE_DIR}/${source}"

 )

set (${sources} ${${sources}} ${source})

 

endforeach(ui_name)

 

# headers contains

#   - headers generated from ui files

#   - headers initially given by the user because they contain
Q_OBJECT macro

foreach(header ${${headers}})

string(REGEX REPLACE "h$" "cxx" moc ${header})

set(moc "moc_${moc}")

add_custom_command(

  OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/${moc}

WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}

  COMMAND ${QT_MOC} ${header} -o ${moc}

  DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${header}

  COMMENT "Generating
${CMAKE_CURRENT_SOURCE_DIR}/${moc}"

 )

set (${sources} ${${sources}} ${moc})

 

endforeach(header)

 

  add_custom_target(ui

DEPENDS ${${sources}} ${${headers}}

  )

endmacro()

 

 

Cordialement / Regards,

Alexandre 





From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Ivan Chupahin
Sent: Thursday, 02 April 2009 11:47
To: cmake@cmake.org
Subject: [CMake] Output directory for genereated ui_Header.h files

 

Hi,folks!

My project uses Qt4 and i need to generate *.h files from *.ui files.
For that i use QT4_WRAP_UI macro. But it generete *.h files in a
derectory where CMake is running. Maybe exist some CMake variable for
point an output directory for that generated files or some other tools? 



This email was sent to you by Thomson Reuters, the global news and information 
company.
Any views expressed in this message are those of the individual sender, except 
where the sender specifically states them to be the views of Thomson Reuters.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Win32: Find location of VS redistributable runtime files ?

[Stephen Collyer]

In the course of installation, I want to copy the redistributable C++
runtime libs
directory from VS into my deliverable package. However, this should work
with
both VS8 and VS9. Could someone tell me how I can detect the build
environment
and locate the appropriate directory to do this ? For example, if building
with
VS9 I want to locate the directory:

C:\Program Files\Microsoft Visual Studio
9.0\VC\redist\x86\Microsoft.VC90.CRT

I'm guessing that there's a CMAKE_* variable that allow me to do this,
but I'm not sure which.

--

Stephen Collyer
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Output directory for genereated ui_Header.h files

[Andreas Pakulat]

On 02.04.09 16:46:51, Ivan Chupahin wrote:
> Hi,folks!
> 
> My project uses Qt4 and i need to generate *.h files from *.ui files. For
> that i use QT4_WRAP_UI macro. But it generete *.h files in a derectory where
> CMake is running.

That is the correct place. All generated files should be in the
build directory and not the source directory. To be able to use 

#include "ui_foo.h"

You should add CMAKE_CURRENT_BINARY_DIR and/or CMAKE_BINARY_DIR to your include
directories.

Andreas

-- 
Your lucky number has been disconnected.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Output directory for genereated ui_Header.h files

[Ivan Chupahin]

Hi,folks!

My project uses Qt4 and i need to generate *.h files from *.ui files. For
that i use QT4_WRAP_UI macro. But it generete *.h files in a derectory where
CMake is running. Maybe exist some CMake variable for point an output
directory for that generated files or some other tools?
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Xcode generator

[Tobias Rudolph]

On 2 Apr 2009, at 02:14, E. Wing wrote:


As you can see, when a rebuild is done, the template gets copied to
"main.cpp" which in turn is compiled and linked. This works great in
Xcode. But, whenever I change the template, i.e. my CUDA sources, I
have to run the build twice to make the changes appear in the test
program. It looks like the custom command is executed during the  
first

run and the generated file gets compiled in the second.

Has anyone ever seen this?




I haven't had your exact problem, but I think I have encountered
something similar which required me to build twice to capture changes.
I think there is a bug in the CMake bootstrap. Since you have a good
reproducible test case, would, I would encourage you to file a bug
report on this in the CMake bug tracker.

Thanks,
Eric


http://public.kitware.com/Bug/view.php?id=8833

cheers,
tobias
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] link_libraries() deprecated. Why?

[Marcel Loose]

Hi Philip,

Thanks for your reply. Your solution is ok, but it looks a bit like a
workaround for a feature that is missing, but was once there:
link_libraries().

To me, it's not really clear why link_libraries() has been deprecated
and, for example, include_directories() has not. IMHO, using
target_link_libraries() for a general library has a too fine
granularity. 
Suppose include_directories() were deprecated as well in favour of, say,
target_include_directories(). That would create the same problem: carry
around variables holding a bunch of include directories that must be
supplied to each target.

I don't like to use deprecated features, so I would love to see the
deprecation of link_libraries() to be reverted. But maybe I'm missing a
good reason for not doing so.

Best regards,
Marcel Loose.


On Wed, 2009-04-01 at 23:50 -0400, Philip Lowman wrote:
> On Wed, Apr 1, 2009 at 5:35 PM, Marcel Loose  wrote:
> Hi all,
> 
> I was wondering why the link_libraries() command has been
> deprecated. Commands like include_directories() and
> link_directories() which have the same "scope" have not been
> deprecated. I think that link_libraries() has its virtues too.
> 
> My reason for asking this, is that I wonder what's the proper
> way to add a library to *all* targets in a project; for
> example, a logging library or a threads library. Here,
> link_libraries() provides IMHO a much cleaner solution, than
> target_link_libraries(). The latter requires me to keep track
> of the globally used library in a variable that must be passed
> around; and for each target I must explicitly specify its
> dependency on this library by using target_link_libraries().
> 
> Or, am I missing something, and is there a cleaner way to do
> this, without using a deprecated feature?
> 
> Often I have seen people write functions to help with this especially
> if you have more than one common library.
> 
> function(link_target_against_common_libs _target)
>target_link_libraries(${_target} ${WHATEVER_LIBRARY})
> endfunction()
> 
> Another approach is if you have a low level library as part of your
> codebase that everyone depends upon you can simply make it dependent
> on your threading or logging libraries and anyone that is dependent
> against it will automatically link against the threading or logging
> library.
> 
> 
> -- 
> Philip Lowman

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] how-to get cmake command line after running ccmake

[Adolfo Rodríguez]

If you do create this script, would you mind sharing it in this list?. I
think it may come in handy to many of us at one time or another.

Thanks in advance!

Adolfo

On Wed, Apr 1, 2009 at 11:06 PM, Darren Weber
wrote:

>
> Yes, this is the feature that I'm looking for.  I want to use ccmake for
> the initial configuration and then automatically "translate" that
> configuration into an equivalent command line for cmake (all on *nix
> system), which I can then put into an automated build script (sh or bash)
> that I can run on other systems (via ssh or whatever).
>
>
> I'll try your diff suggestion James.
>
> Thanks, Darren
>
>
>
> On Mon, Mar 30, 2009 at 9:23 PM, James Bigler wrote:
>
>> On Mon, Mar 30, 2009 at 9:27 PM, Philip Lowman  wrote:
>>
>>> On Mon, Mar 30, 2009 at 4:09 PM, Darren Weber <
>>> darren.weber.li...@gmail.com> wrote:
>>>

 Can we automatically extract an equivalent cmake command line after
 running ccmake?

 Take care, Darren
>>>
>>>
>>> If you're using the Makefile generator you can simply type "make
>>> edit_cache" in your build tree after you've initially generated.
>>>
>>> If this doesn't solve your problem you likely can look towards finding
>>> the source directory in the CMakeCache.txt file.
>>>
>>
>> I think he wants to run ccmake and configure things how he likes and then
>> get a command line that would produce the equivalent configuration without
>> ccmake (i.e. cmake -DSOMEVAR:BOOL=ON
>> -DPATH_TO_SOME_EXE:PATH=/path/to/some.exe).  This way, he can configure a
>> new build in one easy step.
>>
>> I don't believe this feature exists, though you could get something close
>> by doing the following.
>>
>> 1. Create a build directory and run cmake .  This is your
>> default configuration.
>> 2. Copy CMakeCache.txt some where safe.
>> 3. Configure you system with ccmake.
>> 4. Diff the old CMakeCache.txt and the new CMakeCache.txt.  The
>> differences should show you a superset of the options you will need
>> (depending on if some options are automatically generated when you turn
>> others on).
>>
>> James
>>
>> ___
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>



-- 
Adolfo Rodríguez Tsouroukdissian

Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Output directory for generated ui_Header.h from Header.ui

[Ivan Chupahin]

Hi,folks!

My project uses Qt4 and i need to generate *.h files from *.ui files. For
that i use QT4_WRAP_UI macro. But it generete *.h files in a derectory where
CMake is running. Maybe exit some CMake variable for point an output
directory for that generated files or some other tools?
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake