[CMake] ExternalProject_Add show sources in Visual Studio

[NoRulez]

Ok, thank you very much.

I will try your examples.

Best Regards

> Am 19.03.2014 um 15:40 schrieb David Cole <dlrdave at aol.com>:
> 
> 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.
> 
>