<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>