That's one "workaround". Two more come to mind:
(1) Another would be to force the configure/build steps of an external
project to run *always* rather than when the stamp file indicates they
are out of date. You could take a look at the open chemistry super
build to see an example.
Specifically, check out the code here:
https://github.com/OpenChemistry/openchemistry/blob/master/CMakeLists.txt#L32
And here:
https://github.com/OpenChemistry/openchemistry/blob/master/cmake/External_avogadrolibs.cmake#L20
Then, when forced, a build of the outer project will always trigger the
build of the external project and make sure it's up to date with
respect to its own source tree.
But, if you have a lot of these, it just slows your build down in the
normal case of not changing anything in the external projects. So use
it sparingly, not globally.
(2) One more workaround worth mentioning: the manual one.
ExternalProject_Add will generate VS projects for the sub-projects if
they are CMake-based and your containing project is using a VS
generator, and then open the generated sub-projects directly to see the
"normal" view of things. Make mods in there, and build/install in
there, then go back to your containing project, and it's already up to
date.
To each his own... Good luck.
HTH,
David C.
-----Original Message-----
From: NoRulez <noru...@me.com>
To: David Cole <dlrd...@aol.com>
Cc: cmake <cmake@cmake.org>
Sent: Wed, Mar 19, 2014 9:48 am
Subject: Re: [CMake] ExternalProject_Add show sources in Visual Studio
Ok, so the only "workaround" to archive this is to use
"file(GLOB_RECURS...)"
and rebuild the changed external project. Right?
Best Regards
Am 19.03.2014 um 12:44 schrieb David Cole <dlrd...@aol.com>:
Well, that sounds like the perfect way to use ExternalProject.
But why do you want to show the sources in Visual Studio? Just for
ease of
looking at them?
As I said in my earlier reply... even if we showed the sources,
editing them
would not trigger a rebuild of the external project. The dependencies
are
tracked via custom commands and stamp files that indicate last
successful run
time of those custom commands. They are not tracked by Visual Studio on
a
per-source-file/per-obj-file basis as they are in a normal VS project.
The main goal of ExternalProject is to provide an easy-to-use way of
*building*, *installing* and depending on an external project... It is
most
definitely NOT to provide an easy way to do active development on a
project.
If you need to see the sources for something that you're building
within
Visual Studio, then to me, that's a big red flag that it should not be
an
external project.
HTH,
David C.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
