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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Brian Davis-2
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
Reply | Threaded
Open this post in threaded view
|

Re: ExternalProject_Add and include_external_msproject dynamic duo... but what if their powers combined?

Brian Davis-2
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 CMakePackageConfigHelpers 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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: ExternalProject_Add and include_external_msproject dynamic duo... but what if their powers combined?

Brian Davis-2

crickets.... crickets... crickets...

That's the response I get from the internet? 

Here are some other interesting bits:
Does not make any reference to
configure_package_config_file 
in

https://cmake.org/cmake/help/v3.8/module/CMakePackageConfigHelpers.html

But happily goes about telling pkg maintainers to go about and do with config_file what doc on 
configure_package_config_file says not to do... and that is NOT to use configure_file in the first place at:

https://cmake.org/cmake/help/v3.8/manual/cmake-packages.7.html#id16
And then there is INSTALL_DESTINATION in:

configure_package_config_file(<input> <output> INSTALL_DESTINATION <path>

which gives the pkg maintainer just enough rope to hang themselves with.
I mean hey they could (and have) put it just about anywhere like 

${CMAKE_INSTALL_PREFIX}/CMake
or
${CMAKE_INSTALL_PREFIX}/lib/cmake or
${CMAKE_INSTALL_PREFIX}/lib/cmake/pkgname or
${CMAKE_INSTALL_PREFIX}/lib/cmake/pkgname-<version> or
${CMAKE_INSTALL_PREFIX}/share/pkgname or
${CMAKE_INSTALL_PREFIX}/share/cmake/pkgname or
... well you get the idea.  With or without version info. Where IMO 
configure_package_config_file should require version info and put in "standard directory" whatever that may be.
Please someone in internet land tell me I am wrong.

I'll await the crickets.


--

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