[CMake] ExternalProject_Add and include_external_msproject dynamic duo... but what if their powers combined?

Brian Davis bitminer at gmail.com
Thu Mar 30 10:58:49 EDT 2017


Apologies for not responding sooner... this fell off my radar and I found
it in my email.

On Thu, Jan 12, 2017 at 6:29 AM, David Cole  wrote:

> Why not just use a BUILD_COMMAND which builds the VS project using the
> msbuild command line directly?


Do you have an example of this?

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.


I have used BUILD_COMMAND in the past for *attempting* build of boost in
CMake, 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 CMake package support and
install.  Ultimately I was able to get it to work.  I can now build any
version of boost from within CMake simply by selecting version in CMake gui.

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

This is where a programmer comes to the realization of the "wild west" of
3rd Party lib developers use of CMake package.  Some are new to it like
fltk and do not version files or there cmake package directory nor do they
put package files in lib/cmake/flltk-<version>/<pkgfiles> as itk and vmtk
do and instead put it in ${CMAKE_INSTALL_PREFIX}/CMake/<pkgfiles>.  Others
like dcmtk put it in share\dcmtk (again without version info as itk and
vmtk do \lib\cmake\ITK-4.8\<pkgfiles>).  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:

if( CMAKE_HOST_WIN32 )

  string( LENGTH "${CMAKE_CURRENT_SOURCE_DIR}" n )
  if( n GREATER 50 )
    message(
      FATAL_ERROR
      "ITK source code directory path length is too long (${n} > 50)."
      "Please move the ITK source code directory to a directory with a
shorter path."
      )
  endif()

Sadly no and .. ok so it's 50.

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

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 CMake not
supporting CMAKE_<CONFIG>_PREFIX automatically for executables as though
they are second class targets.  Leaving devs to use

SET_TARGET_PROPERTIES(
${APP_NAME} PROPERTIES
        COMPILE_DEFINITIONS "${DEFINITIONS_STRING}"
        DEBUG_POSTFIX ${CMAKE_DEBUG_POSTFIX} )

The guide at https://cmake.org/cmake/help/v3.8/manual/cmake-packages.7.html
is certainly a great start though

include(CMakePackageConfigHelpers)

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 CMake standard/best practices... but CMake/Kitware
could do more to aid 3rd party lib devs.  Added macros to CMakePackage
ConfigHelpers might help.

Then there are the users which install packages, but cant' figure out why
CMake keeps using the installed version of the package as per CMake's
default package definitions and don't realize it has to do with not
specifying HINTS, PATHS, PATH_SUFFIXES

find_package(<package> [version] [EXACT] [QUIET]
             [HINTS path1 [path2 ... ]]
             [PATHS path1 [path2 ... ]]
             [PATH_SUFFIXES suffix1 [suffix2 ...]]


And then makes me question the internal package support bundled with CMake.
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 CMake to crystal ball a
next release) and I had to roll my own.

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


(And CONFIGURE_COMMAND "" since there
> is typically no configure step for VS-based projects...)
>
> Yes this is what I do.



HTH,
David C.



On Thu, Jan 12, 2017 at 2:13 AM, Brian J. Davis  wrote:
> Every time I create a superbuild using ExternalProject_Add sooner or
later a
> project will not support cmake, but will have buried within its bowels  a
> visual studio solution project .sln and sometimes gobs of .vcxproj files
> (read CPython).  Now ofcourse include_external_msproject can do this.  If
> only these two wonder twins (https://en.wikipedia.org/wiki/Wonder_Twins)
> could work together in the same ExternalProject_Add command.  Maybe by
> adding after HG_TAG say VCX_PROJS or some such.
>
> Only thing better would be getting original project maintainer to support
> CMake.
>
> So feature request: Can we get ExternalProject_Add to support visual
studio
> project files?
>
>
>
> --
>
> 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://public.kitware.com/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170330/48cdda43/attachment-0001.html>


More information about the CMake mailing list