[CMake] ExternalProject_Add show sources in Visual Studio

[David Cole]

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 <norulez at me.com>
To: David Cole <dlrdave at aol.com>
Cc: cmake <cmake at 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 <dlrdave at 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.
>