<div dir="ltr">Apologies for not responding sooner... this fell off my radar and I found it in my email.<br><br><span class="gmail-im">On Thu, Jan 12, 2017 at 6:29 AM, David Cole  wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why not just use a BUILD_COMMAND which builds the VS project using the<br>
msbuild command line directly? </blockquote><div><br></div></span><div>Do you have an example of this?<br><br>Even if this is an option it would not seem to allow adding the vcxproj 
project files to VS solution, but may be a better option for the way 
ExternalProject_Add wraps the underlying project and hides all 
sub-project goop in a single target.  With what I am proposing the 
vcxproj files would be added to VS solution as individual targets.<br><br><br></div><div>I have used BUILD_COMMAND in the past for *attempting* build of boost in <span class="gmail-il">CMake</span>,
 but due to complaints on command line argument length in VS had to 
resort to using BUILD_COMMAND to call bjam/b2 in bat file generated 
using configure_file then called from ExternalProject_add.  I then went 
on to write and configure_file the roll my own boost <span class="gmail-il">CMake</span> package support and install.  Ultimately I was able to get it to work.  I can now build any version of boost from within <span class="gmail-il">CMake</span> simply by selecting version in <span class="gmail-il">CMake</span> gui.<br><br></div><div>I
 have been working on a superbuild of superbuilds [Super-E-Duper-Builder
 SEDB / SeeDeb See Dependency downloaded, built and installed) which in 
theory could download, build, and install any C++ code in the Ether that
 ExternalProject_Add supports though zip, git, svn, hg etc.  It's goes 
where ExternalProject add and find_package left the dev community... 
with a finite quantum of tools, but no abilty to get any software  
downloaded, built and installed though say an "ultimate package 
manager".  <br><br>This is where a programmer comes to the realization of the "wild west" of 3rd Party lib developers use of <span class="gmail-il">CMake</span> package.  Some are new to it like fltk and do not version files or there <span class="gmail-il">cmake</span> package directory nor do they put package files in lib/<span class="gmail-il">cmake</span>/flltk-<version>/<<wbr>pkgfiles> as itk and vmtk do and instead put it in ${CMAKE_INSTALL_PREFIX}/<span class="gmail-il">CMake</span>/<wbr><pkgfiles>.  Others like dcmtk put it in share\dcmtk (again without version info as itk and vmtk do \lib\<span class="gmail-il">cmake</span>\ITK-4.8\<pkgfiles>)<wbr>. 
 But ITK is no great example either as on windows has a limit due to 
path length limiting on where ITK can be build (build dir) I think it's 
something like 56 characters (resulting in build paths outside the 
project like C:\itk\src\ITK-4.8.1)  and I have stated my aggravation 
regarding this on ITK's user forum.   I must be joking right?  well from
 ITK root CMakeLists.txt file:<br><br>if( CMAKE_HOST_WIN32 )<br><br>  string( LENGTH "${CMAKE_CURRENT_SOURCE_DIR}" n )<br>  if( n GREATER 50 )<br>    message(<br>      FATAL_ERROR<br>      "ITK source code directory path length is too long (${n} > 50)."<br>      "Please move the ITK source code directory to a directory with a shorter path."<br>      )<br>  endif()<br><br></div><div>Sadly no and .. ok so it's 50.  <br></div><div><br>VMTK
 puts stuff in build dir minus needed libs like tet.lib and nl.lib and 
pkgfiles point back to get this... the build dir and not install dir for
 include files.  I feel like a <span class="gmail-il">CMake</span> package 
marshal trying to herd cats on the internet... lost cause for sure.  
Then there are 3rdParty libs that use superbuild themselves to checkout 
and build various libs (vmtk usign vtk and itk).  VMTK allows user to 
use installed version.  But lets say two 3rd party libs use super build 
to build two different versions of packages such as  fltk or dcmtk and 
install into a single directory ${CMAKE_PACKAGE_PREFIX} = 
C:\projects\proj1\install... what happens to the package files... yep 
the last build blast away the installed package files as no versioning 
was used.  Also 3rdparty lib devs expand vars in installed package files
 and do not use configure_file( ... @ONLY) to keep things relative. <br></div><div><br></div><div>Then
 there is the "roll their own" use of CMAKE_<CONFIG>_PREFIX where 
they don't use (or don't know it exists) it but instead postfix ('d') it
 themselves (fltk) based on build config so if developer comes along and
 sets it as it do ends up with <libname>dd.lib... I mean that's a 
double d lib... and must be for super debugging.  And what is it about <span class="gmail-il">CMake</span>
 not supporting  CMAKE_<CONFIG>_PREFIX automatically for 
executables as though they are second class targets.  Leaving devs to 
use <br><br>SET_TARGET_PROPERTIES(<br>${APP_NAME} PROPERTIES <br>        COMPILE_DEFINITIONS "${DEFINITIONS_STRING}"<br>        DEBUG_POSTFIX ${CMAKE_DEBUG_POSTFIX} )<br><br></div><div>The guide at <a href="https://cmake.org/cmake/help/v3.8/manual/cmake-packages.7.html" target="_blank">https://<span class="gmail-il">cmake</span>.org/<span class="gmail-il">cmake</span>/help/<wbr>v3.8/manual/<span class="gmail-il">cmake</span>-packages.7.<wbr>html</a> is certainly a great start though<br></div><div><pre><span class="gmail-m_-35297995920830458gmail-nb">include</span><span class="gmail-m_-35297995920830458gmail-p">(</span><span class="gmail-m_-35297995920830458gmail-s"><span class="gmail-il">CMake</span><span class="gmail-m_-35297995920830458gmail-highlighted">Package</span>ConfigHelp<wbr>ers</span><span class="gmail-m_-35297995920830458gmail-p">)</span></pre>Could
 do a great deal more to aid in creating some sort of standards and aid 
3rdPart lib devs in putting bits in the right place and correctly 
versioning.  Not to mention... er wait I'll mention it ... 3rd party 
dev's use of project(thirdPartyProjName)  where version info is not used
 so by default on windows CMAKE_INSTALL_PREFIX defaults to C:\Program 
Files\thirdPartyProjName and not thirdPartyProjName-<version> 
where again things can get blasted away.  One could say it's the 3rd 
party lib devs fault for not adhering to <span class="gmail-il">CMake</span> standard/best practices... but <span class="gmail-il">CMake</span>/Kitware could do more to aid 3rd party lib devs.  Added macros to <span class="gmail-m_-35297995920830458gmail-s"><span class="gmail-il">CMake</span><span class="gmail-m_-35297995920830458gmail-highlighted">Package</span>ConfigHelpers</span><span class="gmail-m_-35297995920830458gmail-p"></span> might help.<br></div><div><br></div><div>Then there are the users which install packages, but cant' figure out why <span class="gmail-il">CMake</span> keeps using the installed version of the package as per <span class="gmail-il">CMake</span>'s default package definitions and don't realize it has to do with not specifying HINTS, PATHS, PATH_SUFFIXES<br></div><div><pre><span class="gmail-m_-35297995920830458gmail-n">find_package</span><span class="gmail-m_-35297995920830458gmail-p">(</span><span class="gmail-m_-35297995920830458gmail-o"><</span><span class="gmail-m_-35297995920830458gmail-n">package</span><span class="gmail-m_-35297995920830458gmail-o">></span> <span class="gmail-m_-35297995920830458gmail-p">[</span><span class="gmail-m_-35297995920830458gmail-n">version</span><span class="gmail-m_-35297995920830458gmail-p">]</span> <span class="gmail-m_-35297995920830458gmail-p">[</span><span class="gmail-m_-35297995920830458gmail-n">EXACT</span><span class="gmail-m_-35297995920830458gmail-p">]</span> <span class="gmail-m_-35297995920830458gmail-p">[</span><span class="gmail-m_-35297995920830458gmail-n">QUIET</span><span class="gmail-m_-35297995920830458gmail-p">]</span>
             <span class="gmail-m_-35297995920830458gmail-p">[</span><span class="gmail-m_-35297995920830458gmail-n">HINTS</span> <span class="gmail-m_-35297995920830458gmail-n">path1</span> <span class="gmail-m_-35297995920830458gmail-p">[</span><span class="gmail-m_-35297995920830458gmail-n">path2</span> <span class="gmail-m_-35297995920830458gmail-o">...</span> <span class="gmail-m_-35297995920830458gmail-p">]]</span>
             <span class="gmail-m_-35297995920830458gmail-p">[</span><span class="gmail-m_-35297995920830458gmail-n">PATHS</span> <span class="gmail-m_-35297995920830458gmail-n">path1</span> <span class="gmail-m_-35297995920830458gmail-p">[</span><span class="gmail-m_-35297995920830458gmail-n">path2</span> <span class="gmail-m_-35297995920830458gmail-o">...</span> <span class="gmail-m_-35297995920830458gmail-p">]]</span>
             <span class="gmail-m_-35297995920830458gmail-p">[</span><span class="gmail-m_-35297995920830458gmail-n">PATH_SUFFIXES</span> <span class="gmail-m_-35297995920830458gmail-n">suffix1</span> <span class="gmail-m_-35297995920830458gmail-p">[</span><span class="gmail-m_-35297995920830458gmail-n">suffix2</span> <span class="gmail-m_-35297995920830458gmail-o">...</span><span class="gmail-m_-35297995920830458gmail-p">]]</span></pre><br></div><div>And then makes me question the internal package support bundled with <span class="gmail-il">CMake</span>. 
 Over the years the internal package support has in my experience lagged
 (CUDA .. Though NVIIDA could not decide on any standards as to where to
 put stuff in their releases making it impossible for <span class="gmail-il">CMake</span> to crystal ball a next release) and I had to roll my own.<br><br></div><div>Regarding lib naming convention: If anyone has taken the time to look at boost naming convention for their libs and understand the reasons for it it makes a lot of sense.  Some standards in CMake or at least macros for those who would like to support standardization of lib name, version, 32/64, ms VS, versions etc might make IMO a great addition to CMake<br></div><div><br></div><span class="gmail-im"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(And CONFIGURE_COMMAND "" since there<br>
is typically no configure step for VS-based projects...)<br>
<br></blockquote></span><div>Yes this is what I do.<div class="gmail-yj6qo gmail-ajU"><div id="gmail-:1v2" class="gmail-ajR" tabindex="0"><img class="gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div><div class="gmail-adL"><br> <br></div></div>
<br>
HTH,<br>
David C.<br>
<div><div class="gmail-m_-35297995920830458gmail-h5"><br>
<br>
<br>
On Thu, Jan 12, 2017 at 2:13 AM, Brian J. Davis  wrote:<br>
> Every time I create a superbuild using ExternalProject_Add sooner or later a<br>
> project will not support <span class="gmail-il">cmake</span>, but will have buried within its bowels  a<br>
> visual studio solution project .sln and sometimes gobs of .vcxproj files<br>
> (read CPython).  Now ofcourse include_external_msproject can do this.  If<br>
> only these two wonder twins (<a href="https://en.wikipedia.org/wiki/Wonder_Twins" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki<wbr>/Wonder_Twins</a>)<br>
> could work together in the same ExternalProject_Add command.  Maybe by<br>
> adding after HG_TAG say VCX_PROJS or some such.<br>
><br>
> Only thing better would be getting original project maintainer to support<br>
> <span class="gmail-il">CMake</span>.<br>
><br>
> So feature request: Can we get ExternalProject_Add to support visual studio<br>
> project files?<br>
><br>
><br>
><br>
</div></div>> --<br>
><br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Please keep messages on-topic and check the <span class="gmail-il">CMake</span> FAQ at:<br>
> <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.<span class="gmail-il">cmake</span>.org/Wiki/CMak<wbr>e_FAQ</a><br>
><br>
> Kitware offers various services to support the <span class="gmail-il">CMake</span> community. For more<br>
> information on each offering, please visit:<br>
><br>
> <span class="gmail-il">CMake</span> Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://<span class="gmail-il">cmake</span>.org/<span class="gmail-il">cmake</span>/help/su<wbr>pport.html</a><br>
> <span class="gmail-il">CMake</span> Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://<span class="gmail-il">cmake</span>.org/<span class="gmail-il">cmake</span>/help/co<wbr>nsulting.html</a><br>
> <span class="gmail-il">CMake</span> Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://<span class="gmail-il">cmake</span>.org/<span class="gmail-il">cmake</span>/help/tr<wbr>aining.html</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensou<wbr>rce/opensource.html</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mail<wbr>man/listinfo/<span class="gmail-il">cmake</span></a></div>