Re: [CMake] SWIG_ADD_LIBRARY Documentation?

[Rob McDonald]

Wow.  That is rather subtle/esoteric.  Thanks for chasing that down.

It makes me wonder what use case / platform drove them to even support
the other options -- and to deprecate working functionality.

Looks like I'll stick with MODULE.

Best,

Rob

On Sat, Dec 9, 2017 at 11:46 AM, J. Caleb Wherry <calebwhe...@gmail.com> wrote:
> I think you intuition is spot on here, I also think loading a static lib at
> runtime is strange. That is why I always build the SWIG libs as shared.
>
> To be honest, I don’t even know why static is an option. I’m sure there is
> some case or reason but I wouldn’t ever build it as a static lib.
>
> As for MODULE vs SHARED, here is a good answer:
> https://stackoverflow.com/a/4968940. As the comments point out, it isn’t
> obvious or documented what platforms this is actually for. On windows, you
> get the same dll when you specify either.
>
> If all the SWIG wrappers load the libraries dynamically (which glancing at
> the examples it looks like they do), MODULE is more fitting. However since I
> can’t find much on what platforms actually support this I don’t see the
> point in using it over SHARED.
>
> -Caleb
>
> On Sat, Dec 9, 2017 at 2:26 PM Rob McDonald <rob.a.mcdon...@gmail.com>
> wrote:
>>
>> Thanks much for your patient and detailed answers -- and sorry for
>> dropping the mailing list.
>>
>> It seems very foreign to me to load a static library at runtime -- oh
>> well.
>>
>> How is 'MODULE' different from 'SHARED' ?
>>
>> Rob
>>
>>
>> On Sat, Dec 9, 2017 at 11:08 AM, J. Caleb Wherry <calebwhe...@gmail.com>
>> wrote:
>> > (Adding the CMake list back so others can reference it)
>> >
>> > FYI: I only use the CMake SWIG macros for Java wrappers so my reference
>> > is
>> > for that.
>> >
>> > With Java, the Java wrapper SWIG creates does a load library on the
>> > library
>> > created from the swig_add_library_call. So at the end of the day, it
>> > doesn’t
>> > matter if it’s a shared or static library, the Java 8 JNI can load it. I
>> > have no idea how python deals with the library created from this call.
>> > But
>> > if it deals with loading the lib the same as Java, then it doesn’t
>> > matter.
>> >
>> > For our Java wrappers, I always compile shared libs. And as for mac,
>> > SWIG
>> > has a special convention and names shared libs “name.jnilib”, not the
>> > standard “name.dylib”.
>> >
>> > From a practical standpoint (and my opinion): shared libs are generally
>> > better since they (usually) have a well defined interface and only
>> > include
>> > the code needed for the lib’s interface. A static lib potentially leaks
>> > a
>> > lot more about your build/files/etc instead of shared libs. Shared libs
>> > are
>> > generally smaller too.
>> >
>> > -Caleb
>> >
>> > On Sat, Dec 9, 2017 at 1:00 PM Rob McDonald <rob.a.mcdon...@gmail.com>
>> > wrote:
>> >>
>> >> Ok, thanks.
>> >>
>> >> In the context of a SWIG wrapper, what would happen if I chose STATIC?
>> >>
>> >> I assume it would result in 'mystuff.a' instead of 'mystuff.so' --
>> >> would I then have to re-build Python and statically link that binding
>> >> in to get it all to work?
>> >>
>> >> If I chose SHARED, would it result in 'mystuff.dylib' (on a Mac?).
>> >>
>> >> What is the practical difference of these choices?
>> >>
>> >> Rob
>> >>
>> >>
>> >>
>> >>
>> >> On Sat, Dec 9, 2017 at 9:43 AM, J. Caleb Wherry <calebwhe...@gmail.com>
>> >> wrote:
>> >> > USE_BUILD_SHARED_LIB literally means use whatever is set by
>> >> > BUILD_SHARED_LIBS. Typically, this is the preferred method for either
>> >> > building a static or shared lib since the user can control what they
>> >> > want/need. You don’t have to specify the type of lib to build when
>> >> > calling
>> >> > add_library, it uses shared if BUILD_SHARED_LIBS is true, otherwise
>> >> > static.
>> >> >
>> >> > Otherwise you can specify the TYPE and the user can’t override it,
>> >> > they
>> >> > always get the type of lib you set.
>> >> >
>> >> > -Caleb
>> >> >
>> >> > On Sat, Dec 9, 2017 at 12:23 PM Rob McDonald
>&

Re: [CMake] SWIG_ADD_LIBRARY Documentation?

[Rob McDonald]

Thanks much for your patient and detailed answers -- and sorry for
dropping the mailing list.

It seems very foreign to me to load a static library at runtime -- oh well.

How is 'MODULE' different from 'SHARED' ?

Rob


On Sat, Dec 9, 2017 at 11:08 AM, J. Caleb Wherry <calebwhe...@gmail.com> wrote:
> (Adding the CMake list back so others can reference it)
>
> FYI: I only use the CMake SWIG macros for Java wrappers so my reference is
> for that.
>
> With Java, the Java wrapper SWIG creates does a load library on the library
> created from the swig_add_library_call. So at the end of the day, it doesn’t
> matter if it’s a shared or static library, the Java 8 JNI can load it. I
> have no idea how python deals with the library created from this call. But
> if it deals with loading the lib the same as Java, then it doesn’t matter.
>
> For our Java wrappers, I always compile shared libs. And as for mac, SWIG
> has a special convention and names shared libs “name.jnilib”, not the
> standard “name.dylib”.
>
> From a practical standpoint (and my opinion): shared libs are generally
> better since they (usually) have a well defined interface and only include
> the code needed for the lib’s interface. A static lib potentially leaks a
> lot more about your build/files/etc instead of shared libs. Shared libs are
> generally smaller too.
>
> -Caleb
>
> On Sat, Dec 9, 2017 at 1:00 PM Rob McDonald <rob.a.mcdon...@gmail.com>
> wrote:
>>
>> Ok, thanks.
>>
>> In the context of a SWIG wrapper, what would happen if I chose STATIC?
>>
>> I assume it would result in 'mystuff.a' instead of 'mystuff.so' --
>> would I then have to re-build Python and statically link that binding
>> in to get it all to work?
>>
>> If I chose SHARED, would it result in 'mystuff.dylib' (on a Mac?).
>>
>> What is the practical difference of these choices?
>>
>> Rob
>>
>>
>>
>>
>> On Sat, Dec 9, 2017 at 9:43 AM, J. Caleb Wherry <calebwhe...@gmail.com>
>> wrote:
>> > USE_BUILD_SHARED_LIB literally means use whatever is set by
>> > BUILD_SHARED_LIBS. Typically, this is the preferred method for either
>> > building a static or shared lib since the user can control what they
>> > want/need. You don’t have to specify the type of lib to build when
>> > calling
>> > add_library, it uses shared if BUILD_SHARED_LIBS is true, otherwise
>> > static.
>> >
>> > Otherwise you can specify the TYPE and the user can’t override it, they
>> > always get the type of lib you set.
>> >
>> > -Caleb
>> >
>> > On Sat, Dec 9, 2017 at 12:23 PM Rob McDonald <rob.a.mcdon...@gmail.com>
>> > wrote:
>> >>
>> >> In version 3.8, SWIG_ADD_MODULE was deprecated in favor of
>> >> SWIG_ADD_LIBRARY.  This added the ability to control the TYPE for the
>> >> target.  From the documentation, the options are this:
>> >>
>> >> https://cmake.org/cmake/help/v3.8/module/UseSWIG.html
>> >>
>> >> TYPE <SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS>
>> >>
>> >> However, I can find no documentation of what these options mean and
>> >> why someone would choose one over the other.
>> >>
>> >> I found some developer comments in KitWare's bug tracker proposing a
>> >> change of the default, but it looks like they left it as 'MODULE'.
>> >> https://gitlab.kitware.com/cmake/cmake/merge_requests/253
>> >>
>> >> However, even which TYPE value is default appears undocumented.
>> >>
>> >> If we want to generalize from ADD_LIBRARY, we can get an idea of what
>> >> some of the options generally mean:
>> >> https://cmake.org/cmake/help/v3.0/command/add_library.html
>> >>
>> >> However, that says nothing for USE_BUILD_SHARED_LIBS -- which appears
>> >> to be entirely unique to SWIG_ADD_LIBRARY.  It was also the proposed
>> >> alternate default in the referenced proposal.
>> >>
>> >> So, can anyone explain in the context of SWIG/C++/Python, why I would
>> >> want to choose SHARED, STATIC, or USE_BUILD_SHARED_LIBS?  What would
>> >> be the practical impact on my wrapper, how it is built, its
>> >> dependencies, etc.
>> >>
>> >> Thanks for any help,
>> >>
>> >> Rob
>> >> --
>> >>
>> >> Powered by www.kitware.com
>> >>
>> >> Please keep messages on-topic and check the CMake FAQ at:
>> >> http://www.

[CMake] SWIG_ADD_LIBRARY Documentation?

[Rob McDonald]

In version 3.8, SWIG_ADD_MODULE was deprecated in favor of
SWIG_ADD_LIBRARY.  This added the ability to control the TYPE for the
target.  From the documentation, the options are this:

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

TYPE 

However, I can find no documentation of what these options mean and
why someone would choose one over the other.

I found some developer comments in KitWare's bug tracker proposing a
change of the default, but it looks like they left it as 'MODULE'.
https://gitlab.kitware.com/cmake/cmake/merge_requests/253

However, even which TYPE value is default appears undocumented.

If we want to generalize from ADD_LIBRARY, we can get an idea of what
some of the options generally mean:
https://cmake.org/cmake/help/v3.0/command/add_library.html

However, that says nothing for USE_BUILD_SHARED_LIBS -- which appears
to be entirely unique to SWIG_ADD_LIBRARY.  It was also the proposed
alternate default in the referenced proposal.

So, can anyone explain in the context of SWIG/C++/Python, why I would
want to choose SHARED, STATIC, or USE_BUILD_SHARED_LIBS?  What would
be the practical impact on my wrapper, how it is built, its
dependencies, etc.

Thanks for any help,

Rob
-- 

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

[CMake] CMAKE_POSITION_INDEPENDENT_CODE Version

[Rob McDonald]

CMAKE_POSITION_INDEPENDENT_CODE first appears in the documentation for
2.8.9 while CMAKE_POSITION_INDEPENDENT_FLAGS appears in the docs for
2.8.8 -- with the same description.

Was this just a documentation typo, or did the name of this variable
change from 2.8.8 to 2.8.9?  Only the _FLAGS version is tracked in the
compatibility matrix on the Wiki...

https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix

Which should I use to work with the widest range of CMake versions?

Rob
-- 

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

[CMake] Version compatibility?

[Rob McDonald]

Is there a continuation of the CMake version -- feature mapping table?

https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix

I found this to be quite useful, but need something that continues into 3.X.

Rob
-- 

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

[CMake] FindFLTK behavior changes between Ubuntu 14.04 and 15.10

[Rob McDonald]

On Ubuntu 14.04 (CMake 2.8.12.2), FindFLTK.cmake sets
FLTK_FLUID_EXECUTABLE to '/usr/bin/fluid'.  This is good.

On 15.10 (CMake 3.2.2), FLTK_FLUID_EXECUTABLE gets set to 'fluid'.  This is bad.

An eyeball comparison of the FindFLTK.cmake scripts included with each
doesn't reveal anything suspicious.  On another mailing list, someone
suggested that the root cause of the change could be a change in bash
behavior.

Does anyone know what caused this?  Does anyone have a workaround?

Is there a way to set the CMake variable to the result of a 'which' command?

Thanks for any help,

Rob
-- 

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

[CMake] SuperProject package/install

[Rob McDonald]

All,

I have a SuperProject set up with ExternalProject_add the way some
other projects do.

The SuperProject has two EP's -- Libraries and Main.  Libraries has a
bunch of its own EP's.  Main is my core project.

When some users use this setup, they're confused at the end --
everything has worked, but the project hasn't been installed, and the
results of compilation are buried several directories deep.

My Main project has a 'package' target set up by CPack.  I'd like the
SuperProject to conclude by executing that build target, and then
copying the resulting file to the top-level build directory from the
SuperProject.  To complicate things, the target file name is not
fixed, it uses the version number -- which is not known to the
SuperProject level.

Right now, the Main ExternalProject_add INSTALL_COMMAND is "".  How
can I change this (or add another step) to build the package target (I
don't want to just hard-code make package, as it should work with MSVC
too).  I've tried things like '${CMAKE_COMMAND} cmake--build package'
but haven't had any luck.

Once I get package running, how can I get the system to copy the
resulting *.zip file out to the top level directory?  I'd like it to
end up in the CMake build directory at the top of the SuperProject,
but I haven't figured out how to make that happen yet.

Thanks,

Rob
-- 

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

Re: [CMake] Statically link OpenMP on Mac gcc

[Rob McDonald]

On a Mac, using GCC's global -static is bad, so that doesn't work out.

However, as it turns out, -static-libgcc implies all parts of libgcc,
including libgomp.  So, building with -static-libgcc -static-libstdc++
looks like the best solution.

Rob


On Thu, Apr 30, 2015 at 2:19 PM, Rob McDonald rob.a.mcdon...@gmail.com wrote:
 I'm using MacPorts GCC 4.8 and CMake 3.2.

 I use 'FIND_PACKAGE( OpenMP )', and then use OpenMP_C_FLAGS and
 OpenMP_CXX_FLAGS appropriately.

 My application works on the machine that I build on.  However, users
 without MacPorts GCC installed can't find libgomp.1.dylib on their
 machine.

 I'd like to tell GCC to statically link libgomp.  I think the global
 -static flag may do this, but it seems like a fairly brutish way of
 getting the job done.

 Is there a way to get CMake to tell GCC to statically link libgomp?
 Or to have more fine grained control over which libraries are static
 vs. dynamic?

 Is there any reason to not want to use the global -static?

 FindOpenMP.cmake isn't like most other Find*.cmake scripts -- instead
 of searching for a *.h, *.a, *.so, or *.dylib file, it checks various
 flags to the compiler -fopenmp, /openmp, etc.  From that, it
 determines the appropriate flags, but there isn't any
 ${OPENMP_LIBRARIES} to use in a later TARGET_LINK_LIBRARIES later on.

 Thanks,

 Rob
-- 

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

[CMake] Statically link OpenMP on Mac gcc

[Rob McDonald]

I'm using MacPorts GCC 4.8 and CMake 3.2.

I use 'FIND_PACKAGE( OpenMP )', and then use OpenMP_C_FLAGS and
OpenMP_CXX_FLAGS appropriately.

My application works on the machine that I build on.  However, users
without MacPorts GCC installed can't find libgomp.1.dylib on their
machine.

I'd like to tell GCC to statically link libgomp.  I think the global
-static flag may do this, but it seems like a fairly brutish way of
getting the job done.

Is there a way to get CMake to tell GCC to statically link libgomp?
Or to have more fine grained control over which libraries are static
vs. dynamic?

Is there any reason to not want to use the global -static?

FindOpenMP.cmake isn't like most other Find*.cmake scripts -- instead
of searching for a *.h, *.a, *.so, or *.dylib file, it checks various
flags to the compiler -fopenmp, /openmp, etc.  From that, it
determines the appropriate flags, but there isn't any
${OPENMP_LIBRARIES} to use in a later TARGET_LINK_LIBRARIES later on.

Thanks,

Rob
-- 

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

[CMake] ExternalProject_Add not re-building when source changes

[Rob McDonald]

I've used ExternalProject_Add to trick CMake into supporting two
compilers to build my project.

Part of my project needs OpenMP, but other parts do not.  So, on
MacOS, I would prefer to build most of the project with CLang, but the
OpenMP requiring part with gcc.

I have CMake set up to detect whether the compiler supports OpenMP.
If it does not, it checks for a user-supplied alternate compiler.

If the user has supplied an alternate compiler, CMake treats the
current directory as an ExternalProject , but passes the alternate
OpenMP capable compiler.

In general, this works well.  However, this arrangement does not
notice when the source files have changed and cause the External
Project to rebuild.

I'm using ExternalProject_ForceBuild to try to make the EP build every
time -- that works, but once inside the EP, make doesn't recognize
that the source files have been updated.

The meat of the situation is something like this

ExternalProject_Add( MYPROJECT
URL ${CMAKE_CURRENT_SOURCE_DIR}
CMAKE_ARGS -DCMAKE_C_COMPILER=${C_ALTERNATE_COMPILER}
-DCMAKE_CXX_COMPILER=${CXX_ALTERNATE_COMPILER}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DEP_BUILD=TRUE
INSTALL_COMMAND 
)
EP_ForceBuild( MYPROJECT )

I use the -DEP_BUILD=TRUE as an extra safety to prevent infinite
recursion -- if the user supplied a non OpenMP capable compiler as the
ALTERNATE_COMPILER.

So, I think the problem is with my use of 'URL
${CMAKE_CURRENT_SOURCE_DIR}'.  Is there a better way to achieve the
same thing?

Thanks in advance,

Rob
-- 

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

[CMake] FindOpenMP not working on VS2010 Pro

[Rob McDonald]

For some reason, FindOpenMP succeeds -- but reports failure for me on
Visual Studio 2010 Pro.  This is with the latest CMake just in case...

1  -- Try OpenMP C flag = [/openmp]
1  -- Performing Test OpenMP_FLAG_DETECTED
1  -- Performing Test OpenMP_FLAG_DETECTED - Success
1  -- Try OpenMP CXX flag = [/openmp]
1  -- Performing Test OpenMP_FLAG_DETECTED
1  -- Performing Test OpenMP_FLAG_DETECTED - Success
1  -- Could NOT find OpenMP (missing:  OpenMP_C_FLAGS OpenMP_CXX_FLAGS)


Any suggestions?
-- 

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

Re: [CMake] FindOpenMP not working on VS2010 Pro

[Rob McDonald]

Sorry for the noise.  My Cache had variables leftover from VS 2010 Express.

Thanks,

Rob

On Wed, Apr 8, 2015 at 3:44 PM, Rob McDonald rob.a.mcdon...@gmail.com wrote:
 For some reason, FindOpenMP succeeds -- but reports failure for me on
 Visual Studio 2010 Pro.  This is with the latest CMake just in case...

 1  -- Try OpenMP C flag = [/openmp]
 1  -- Performing Test OpenMP_FLAG_DETECTED
 1  -- Performing Test OpenMP_FLAG_DETECTED - Success
 1  -- Try OpenMP CXX flag = [/openmp]
 1  -- Performing Test OpenMP_FLAG_DETECTED
 1  -- Performing Test OpenMP_FLAG_DETECTED - Success
 1  -- Could NOT find OpenMP (missing:  OpenMP_C_FLAGS OpenMP_CXX_FLAGS)


 Any suggestions?
-- 

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

Re: [CMake] ExternalProject_Add contributing to top-level Package

[Rob McDonald]

Ok, I think I've answered my own question...

I added the following after the ExternalProject_Add command...

ExternalProject_Get_Property( ALTBUILD BINARY_DIR )
INSTALL( PROGRAMS ${BINARY_DIR}/myprogram DESTINATION . )

Rob


On Sat, Apr 4, 2015 at 12:57 PM, Rob McDonald rob.a.mcdon...@gmail.com wrote:
 All,

 I have a project that is typically compiled with CLang/LLVM.  However,
 I'm now adding a component that is preferentially built with OpenMP.
 CLang doesn't support OpenMP, so I'd like to build that component with
 GCC while still building everything else with CLang.

 So far, I'm approaching the problem as shown in the below
 CMakeLists.txt.  The program understands -DUSE_OPENMP, so if OpenMP
 isn't found, it will build a uni-processor version.  The user can
 optionally pass -DC_OMP_COMPILER and -DCXX_OMP_COMPILER when CMake is
 run.  Those will specify alternate OpenMP capable compilers.  The
 EP_BUILD variable prevents infinite recursion.

 So, in the case where the primary compiler does not support OpenMP,
 and the user specifies an alternate compiler, this will use
 ExternalProject_Add to establish a new build environment with the
 alternate compiler, and build that.  So far, so good.

 The problem I have is that I would like the executable built by
 ExternalProject to be added to the top-level project's package.  So,
 instead of the recursion protected INSTALL at the bottom, I want a
 roughly equivalent INSTALL command that specifically works in the
 ExternalProject case.

 Best,

 Rob

 #
 FIND_PACKAGE( OpenMP )

 if(OPENMP_FOUND)
   set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS} -DUSE_OPENMP)
   set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS} -DUSE_OPENMP)
   set(BUILD_IT true)
 else()

 if( CXX_OMP_COMPILER AND NOT EP_BUILD )

   INCLUDE( ExternalProject )

   set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake 
 ${CMAKE_MODULE_PATH})
   INCLUDE( ExternalProject_ForceBuild )

   ExternalProject_Add( ALTBUILD
 URL ${CMAKE_CURRENT_SOURCE_DIR}
 CMAKE_ARGS -DCMAKE_C_COMPILER=${C_OMP_COMPILER}
 -DCMAKE_CXX_COMPILER=${CXX_OMP_COMPILER}
 -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
 -DEP_BUILD=TRUE
 INSTALL_COMMAND 
 )
 EP_ForceBuild( ALTBUILD )

   else()
 set(BUILD_IT true)
   endif()
 endif()

 if(BUILD_IT)

   ADD_EXECUTABLE( myprogram
   main.cpp
   )

   TARGET_LINK_LIBRARIES( myprogram
   )

   if ( NOT EP_BUILD )
 INSTALL( TARGETS myprogram RUNTIME DESTINATION . )
   endif()

 endif()
-- 

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

[CMake] ExternalProject_Add contributing to top-level Package

[Rob McDonald]

All,

I have a project that is typically compiled with CLang/LLVM.  However,
I'm now adding a component that is preferentially built with OpenMP.
CLang doesn't support OpenMP, so I'd like to build that component with
GCC while still building everything else with CLang.

So far, I'm approaching the problem as shown in the below
CMakeLists.txt.  The program understands -DUSE_OPENMP, so if OpenMP
isn't found, it will build a uni-processor version.  The user can
optionally pass -DC_OMP_COMPILER and -DCXX_OMP_COMPILER when CMake is
run.  Those will specify alternate OpenMP capable compilers.  The
EP_BUILD variable prevents infinite recursion.

So, in the case where the primary compiler does not support OpenMP,
and the user specifies an alternate compiler, this will use
ExternalProject_Add to establish a new build environment with the
alternate compiler, and build that.  So far, so good.

The problem I have is that I would like the executable built by
ExternalProject to be added to the top-level project's package.  So,
instead of the recursion protected INSTALL at the bottom, I want a
roughly equivalent INSTALL command that specifically works in the
ExternalProject case.

Best,

Rob

#
FIND_PACKAGE( OpenMP )

if(OPENMP_FOUND)
  set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS} -DUSE_OPENMP)
  set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS} -DUSE_OPENMP)
  set(BUILD_IT true)
else()

if( CXX_OMP_COMPILER AND NOT EP_BUILD )

  INCLUDE( ExternalProject )

  set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake ${CMAKE_MODULE_PATH})
  INCLUDE( ExternalProject_ForceBuild )

  ExternalProject_Add( ALTBUILD
URL ${CMAKE_CURRENT_SOURCE_DIR}
CMAKE_ARGS -DCMAKE_C_COMPILER=${C_OMP_COMPILER}
-DCMAKE_CXX_COMPILER=${CXX_OMP_COMPILER}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DEP_BUILD=TRUE
INSTALL_COMMAND 
)
EP_ForceBuild( ALTBUILD )

  else()
set(BUILD_IT true)
  endif()
endif()

if(BUILD_IT)

  ADD_EXECUTABLE( myprogram
  main.cpp
  )

  TARGET_LINK_LIBRARIES( myprogram
  )

  if ( NOT EP_BUILD )
INSTALL( TARGETS myprogram RUNTIME DESTINATION . )
  endif()

endif()
-- 

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

[CMake] Matlab producing image files for use with LaTeX

[Rob McDonald]

I am familiar with UseLATEX, but would like to take the automation of
my document build system a step or two further.  Solutions that build
on UseLATEX -- or a totally separate approach, are OK.

I often use Matlab to create *.pdf figures -- which are then used in a
LaTeX document.  I would like my build setup to notice when a Matlab
*.m file has changed - and then re-run it to re-generate the dependent
*.pdf - and then LaTeX for the final document.

If that works, I would like to take things a step further and specify
that the *.m files may depend on some external data files of arbitrary
formats.  The whole system should notice and update when those data
files are updated.

Bonus points for a system that detects as much of the dependencies
automagically (like #include ing header files).

Any suggestions?

Rob
-- 

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

[CMake] Path vs. name preference during search.

[Rob McDonald]

When I search for a given library, specifying multiple possible names and
multiple hints for paths...

FIND_LIBRARY( FINDME_LIB
NAMES name1 name2 name3
HINTS path1 path2 path3
DOC Library to find)

CMake seems to have a preference for name1, and it first searches all HINTS
for name1.  If it doesn't find name1, it moves to name2 and then searches
all HINTS for name2, etc.

I would prefer to have a preference for path1, no matter the name.  Try for
all names in path1, then move to path2, etc.

Is there a way to toggle this behavior?

Rob


Background...  Basically, I am using ExternalProject_Add to build a
library.  However, to make it possible to use the system-library instead,
this is optional.  I use a FindThelib.cmake so the main project works
seamlessly either way.

I'm targeting the case where a version of this library is installed on the
system, but I want to use my own copy.

The name of the library depends on build options and platform, so
controlling on the name is a little fragile.  However, I have explicitly
built it in a known directory, so having preference for the known directory
is desirable.
-- 

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Path vs. name preference during search.

[Rob McDonald]

Jc,

That is an approach I have thought about.  I even think I have looked at
Slicer for how you work your CMake system.

I prefer to use project-supplied FindLIB.cmake (or a slightly modified
version thereof) because some of them do more than just setting LIBRARY,
INCLUDE_DIR, and FOUND variables.

Rather than duplicate everything done in the FindLIB.cmake script (which
can have platform-dependent logic), I have gone the path of encouraging the
FindLIB.cmake to find the one I want.

Rob



On Thu, Feb 13, 2014 at 10:09 AM, Jean-Christophe Fillion-Robin 
jchris.filli...@kitware.com wrote:

 Hi Rob,

 Do address the use case you described, I usually explicitly set the path
 the library when built as an external project and rely only on the find_*
 command for the use_system case.

 See
 https://github.com/Slicer/Slicer/blob/c5a39acf7af28ba82cc0097c84d1ebda89cce3b4/SuperBuild/External_teem.cmake#L13-16

 Hth
 Jc


 On Thu, Feb 13, 2014 at 12:51 PM, Rob McDonald 
 rob.a.mcdon...@gmail.comwrote:

 When I search for a given library, specifying multiple possible names and
 multiple hints for paths...

 FIND_LIBRARY( FINDME_LIB
 NAMES name1 name2 name3
 HINTS path1 path2 path3
 DOC Library to find)

 CMake seems to have a preference for name1, and it first searches all
 HINTS for name1.  If it doesn't find name1, it moves to name2 and then
 searches all HINTS for name2, etc.

 I would prefer to have a preference for path1, no matter the name.  Try
 for all names in path1, then move to path2, etc.

 Is there a way to toggle this behavior?

  Rob


 Background...  Basically, I am using ExternalProject_Add to build a
 library.  However, to make it possible to use the system-library instead,
 this is optional.  I use a FindThelib.cmake so the main project works
 seamlessly either way.

 I'm targeting the case where a version of this library is installed on
 the system, but I want to use my own copy.

 The name of the library depends on build options and platform, so
 controlling on the name is a little fragile.  However, I have explicitly
 built it in a known directory, so having preference for the known directory
 is desirable.

 --

 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://www.cmake.org/mailman/listinfo/cmake




 --
 +1 919 869 8849

-- 

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://www.cmake.org/mailman/listinfo/cmake

[CMake] Determining appropriate CMAKE_MINIMUM_REQUIRED

[Rob McDonald]

Is there a way to get cmake to report back an _actual_ minimum required
version?

Our project has lots of parts, and the CMakeLists.txt have not been very
well maintained.  Right now, CMAKE_MINIMUM_REQUIRED is set to different
values throughout, none of which are likely correct.

It seems like it 'ought to be possible' to run a new version of cmake and
have it report out actual values for CMAKE_MINIMUM_REQUIRED.

Is there any way to do this other than a manual audit?

Best,

Rob
-- 

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://www.cmake.org/mailman/listinfo/cmake

[CMake] Path too long

[Rob McDonald]

All,

I'm building FLTK as an ExternalProject to a 'Libraries' project.  Inside
the ExternalProject, I'm using the FLTK CMake build system.

I've then created a SuperProject to build Libraries as an ExternalProject
(and my main project too).  This works great so far on my Mac.

On my Windows machine, this results in a path name longer than 256
characters for the innermost FLTK CMake run.  This fails to write a file,
which causes the build to fail.  Which causes the whole thing to fall down.
 The specific innermost error is this

5CUSTOMBUILD : CMake error : cannot write to file
C:/Users/ramcdona/Documents/OpenVSP/refactor/build/super/Libraries-prefix/src/Libraries-build/FLTK-prefix/src/FLTK-build/CMakeFiles/Export/C_/Users/ramcdona/Documents/OpenVSP/refactor/build/super/Libraries-prefix/src/Libraries-build/FLTK-prefix/CMake/FLTKLibraries.cmake:
No such file or directory

Beautiful, isn't it?

Although I can obviously work around this by using some alternate
less-buried directory, that is a fragile solution that is not user-proof.
 Is there some way around this?  What have other projects with big
SuperBuild's done?

Rob
-- 

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] AStyle or similar code beautifier

[Rob McDonald]

Thanks to everyone for all the helpful responses.  It looks like most of
the ideas were pretty similar to what I was thinking.  Glad to know I
wasn't missing anything huge.

I had found UniversalIndentGUI and plan on using it.  I had also found
uncrustify and will take a closer look at it.


On Fri, Jan 31, 2014 at 1:55 AM, Игорь Пашев pashev.i...@gmail.com wrote:

 Code formatting is completely out of scope of building system.



I think that CMake has historically trended towards an expansionist view of
what it can/should be used for, not a restrictionist one.  I think a lot of
the other posters make good cases for why this may be a good idea.

In general, I think of CMake as a tool that helps to standardize working
with code.  That can be cross platform builds, support for build farms and
unit testing, automatic documentation generation, packaging of the project,
etc.

I want to clean up a large codebase with years of formatting neglect in an
automated way.  AStyle or Uncrustify are the right tool for this.  I would
like to give my team an easy way to check the formatting against the same
style.  Including a config file or the full command line with options is a
good tool for this.  My team works on different platforms, so a
FindAStyle.cmake which just uses Find_Program and CMake's cross platform
scripting are good solutions to make this easy.  Including format checking
or reformatting as build targets increase the probability that my team will
use these tools.  With CMake, those build targets show up for my team, no
matter whether they use Make, Visual Studio, Eclipse, etc.

If our project someday graduates to a more advanced level, then the kind of
integration that BRL-CAD uses with automatic format checks with warnings on
every build could be a good step -- and CMake would be a good tool to help
make that happen.

Rob
-- 

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://www.cmake.org/mailman/listinfo/cmake

[CMake] AStyle or similar code beautifier

[Rob McDonald]

All,

I'm interested in adding a code beautifier to my project.  I'm looking at
AStyle, but am open to others.

Implementing a FindAStyle.cmake is pretty trivial.  Likewise, implementing
custom targets is pretty straightforward in the simple case.

However, I thought there might be some canonical/idiomatic examples of this
sort of thing.  Any pointers to projects that do this particularly well?
 Are there any other code beautifiers that already have CMake support?

Thanks,

Rob
-- 

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://www.cmake.org/mailman/listinfo/cmake

[CMake] Reverse logic

[Rob McDonald]

I feel like this is a really dumb question, but I've got myself wrapped
around the axel

I'd like to use a negative conditional on a variable that may or may not be
defined...  say USE_SYSTEM_FOO

So, I'd like to do something like this...

IF( NOT ${USE_SYSTEM_FOO} )
# Build my own FOO
ENDIF()

However, this does not work as desired.  On the other hand, the following
version does have the desired behavior (shouldn't these be the same?).

IF( ${USE_SYSTEM_FOO} )
ELSE()
# Build my own FOO
ENDIF()

I tried a couple of combinations with DEFINED thrown in.  They didn't work
as desired either.  I didn't chase after a compound conditional like the
following simply due to ugliness

IF( NOT DEFINED ${USE_SYSTEM_FOO} OR NOT ${USE_SYSTEM_FOO} )
# Build my own FOO
ENDIF()

What is the CMake idiomatic way to do this?

BTW, I'm going to do a bunch of these, and I'd like to surround them with a
global USE_SYSTEM_LIBRARIES, so solutions that don't get exponentially
uglier with linear increases in complexity are desired.

Rob
-- 

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://www.cmake.org/mailman/listinfo/cmake

[CMake] Compiling two versions of file/program

[Rob McDonald]

My project can be compiled with support for graphics, or in a completely
headless mode with no dependencies on any graphics libraries.  By and
large, this is accomplished with the same source code and a very few
#define 's.

We also have an API/Library mode with no main(), but that can have graphics
or not.

I'd like to use CMake to compile both versions of these in one go.
 However, I don't see any way to make a -DFOO for just a single file, or to
compile two versions of a single object to then be used later.

I think the workaround will be to have two CMakeLists.txt a level deeper
than the file with main().


\maindir
  CMakeLists.txt_1
  main.cpp
\maindir\graphics
  CMakeLists.txt_2
\maindir\headless
  CMakeLists.txt_3

Where...
CMakeLists.txt_1 is basically:
add_directory( graphics )
add_directory( headless )

And then _2 and _3 set the -DFOO at their level and include the source with
a ../main.cpp

Is there another/better way?

Rob
-- 

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Compiling two versions of file/program

[Rob McDonald]

On Mon, Jan 20, 2014 at 7:39 AM, J Decker d3c...@gmail.com wrote:

 On Mon, Jan 20, 2014 at 7:37 AM, Игорь Пашев pashev.i...@gmail.com
 wrote:
  2014/1/20 Rob McDonald rob.a.mcdon...@gmail.com:
  We also have an API/Library mode with no main(), but that can have
 graphics
  or not.
 
  So, one will have the library with unpredictable API/ABI?
 
 Ya; probably something like VLC, that gets a predictable API later
 through documentation...


The current plan is to keep all the calls available, but turn them into
no-op's on the graphics version.

The graphics/gui side is only relevant for visualization and interactive
use.  So, if you're switching to a truly headless batch-only mode, then the
behavior of no-op calls to the graphics parts of the API will be the same
as what is really desired.

In many ways, the graphics version of the API is like a debug mode.  It'll
be very useful for developing a batch mode program, but when you go to
production, it won't make a difference.

Rob
-- 

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] patch on Windows

[Rob McDonald]

 On Sun, Jan 12, 2014 at 1:39 AM, Rob McDonald rob.a.mcdon...@gmail.comwrote:

 Where does CMake get its patch implementation?


 It doesn't. It would be great if CMake implemented a cmake -E patch.


Agreed.



 Problem is patch from GNUWin32 does not support Unix line endings (it will
 crash), therefore I am forced to use Windows line endings in every patch
 (unix2dos is your friend).


I found that I could work around this with the --binary flag passed to
patch on Windows.

Rob
-- 

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://www.cmake.org/mailman/listinfo/cmake

[CMake] patch on Windows

[Rob McDonald]

Where does CMake get its patch implementation?

I'm using a patch step with ExternalProject_Add on Windows (and other
platforms).

I had it working on one Windows machine - which unfortunately just got
knocked off a desk and will never be recovered.  The same files on a
different Windows machine doesn't work.

'patch' is not recognized as an internal or external command.

Looks like CMake can't find 'patch', but I thought it was built-in.  I was
using 2.8.8, but when I ran into this, I upgraded to 2.8.12.1 -- no change.

Since I can no longer boot the other computer, I'm having a hard time
figuring out what the difference is...

Working configuration -- Windows XP, Visual Studio 2010, Mingw probably
installed someplace, CMake 2.8.6 (maybe).

Broken configuration -- Windows 7, Visual Studio 2008, no Mingw, Cygwin, or
other unix-ish stuff installed.  CMake 2.8.8 then 2.8.12.1

Even if I sort out the difference, I'd like to be able to count on this for
my developers without making them install additional dependencies.  Is
there a FindPATCH.cmake I need to use?  For Windows patching, am I better
off just carrying new copies of the changed files and copying them over in
the patch step?

Thanks in advance,

Rob
-- 

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Fwd: Visual Studio command line from CMake

[Rob McDonald]

Correct, this is one of the concerns that makes it more complex than just
searching for the first vcvarsall.bat you come to.

I'd like to match up the vcvarsall to the version of visual studio
currently in use by CMake.

I think there are now enough pieces that I can write a CMake
'FindVSEnvironment.cmake'.  While I can't test it for a large number of
MSVC versions, I'll post it and hopefully others can help out.

Rob


On Thu, Jan 9, 2014 at 6:44 AM, John Drescher dresche...@gmail.com wrote:

  Why not just write your own batch ('buildit.bat') file that does:
 
 call vcvarsall.bat
 nmake
 
  (or whatever the command to build in the VS command prompt is...)
 
  And then your command to build is:
 
 C:/full/path/to/buildit.bat
 
  It's presumably in a Windows-specific chunk of your CMakeLists anyway, so
  that should work fairly simply.

 I think the part of problem would be figuring out what vcvarsall.bat
 to run especially if you have more than 1 version of Visual Studio.

 John

--

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Fwd: Visual Studio command line from CMake

[Rob McDonald]

All,

Thanks for all the help, I'm getting closer.  My current approach does
this

CMAKE_MINIMUM_REQUIRED( VERSION 2.8 )
INCLUDE( ExternalProject )

SET( VS_MAKEFILE_ZIP vsnet-makefiles.0.85.zip )

IF( MSVC )
  IF( MSVC_VERSION EQUAL 1200 )
SET( VS_TOOLS_PATH $ENV{VS60COMNTOOLS} )
SET( VS_ENV_BAT ${VS_TOOLS_PATH}vsvars32.bat )
  ELSEIF( MSVC_VERSION EQUAL 1300 )
SET( VS_TOOLS_PATH $ENV{VS70COMNTOOLS} )
SET( VS_ENV_BAT ${VS_TOOLS_PATH}vsvars32.bat )
  ELSEIF( MSVC_VERSION EQUAL 1310  )
SET( VS_TOOLS_PATH $ENV{VS71COMNTOOLS} )
SET( VS_ENV_BAT ${VS_TOOLS_PATH}vsvars32.bat )
  ELSEIF( MSVC_VERSION EQUAL 1400 )
SET( VS_TOOLS_PATH $ENV{VS80COMNTOOLS} )
SET( VS_ENV_BAT ${VS_TOOLS_PATH}vsvars32.bat )
  ELSEIF( MSVC_VERSION EQUAL 1500 )
SET( VS_TOOLS_PATH $ENV{VS90COMNTOOLS} )
SET( VS_ENV_BAT ${VS_TOOLS_PATH}vsvars32.bat )
  ELSEIF( MSVC_VERSION EQUAL 1600 )
SET( VS_TOOLS_PATH $ENV{VS100COMNTOOLS} )
SET( VS_ENV_BAT ${VS_TOOLS_PATH}vsvars32.bat )
  ELSEIF( MSVC_VERSION EQUAL 1700 )
SET( VS_TOOLS_PATH $ENV{VS110COMNTOOLS} )
SET( VS_ENV_BAT ${VS_TOOLS_PATH}VsDevCmd.bat )
  ELSEIF( MSVC_VERSION EQUAL 1800 )
SET( VS_TOOLS_PATH $ENV{VS120COMNTOOLS} )
SET( VS_ENV_BAT ${VS_TOOLS_PATH}VsDevCmd.bat )
  ENDIF( MSVC_VERSION EQUAL 1200 )
ENDIF ( MSVC )

file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/opts.txt
R
V)

file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/runthis.bat
call \${VS_ENV_BAT}\
gmake  opts.txt)

ExternalProject_Add( FLTK
  URL ${CMAKE_SOURCE_DIR}/fltk-1.3.2-source.tar
  UPDATE_COMMAND
${CMAKE_COMMAND} -E copy_if_different
${CMAKE_SOURCE_DIR}/${VS_MAKEFILE_ZIP}
SOURCE_DIR/${VS_MAKEFILE_ZIP}
  COMMAND
${CMAKE_COMMAND} -E tar -xzf SOURCE_DIR/${VS_MAKEFILE_ZIP}
  COMMAND
${CMAKE_COMMAND} -E copy_if_different
${CMAKE_CURRENT_BINARY_DIR}/opts.txt
SOURCE_DIR/opts.txt
  COMMAND
${CMAKE_COMMAND} -E copy_if_different
${CMAKE_CURRENT_BINARY_DIR}/runthis.bat
SOURCE_DIR/runthis.bat

  PATCH_COMMAND 
  CONFIGURE_COMMAND runthis.bat
  BUILD_COMMAND 
  INSTALL_COMMAND 
  BUILD_IN_SOURCE 1
)


It doesn't fully work.

-- I create the opts.txt and runthis.bat files in CMAKE_CURRENT_BINARY_DIR
and then copy them to SOURCE_DIR.  I couldn't figure out how to write
them within ExternalProject_Add and SOURCE_DIR doesn't exist before
unless I want to reset its value.  Suggestions Welcome.

-- opts.txt and runthis.bat end up where I want them and contain what I
want.

-- If you double-click runthis.bat, it successfully builds FLTK.

-- However, running 'runthis.bat' from inside ExternalProject fails.  I've
tried 'cmd runthis.bat' 'SOURCE_DIR/runthis.bat' and a few other things,
none work.

I think it may be a problem with the command to run the batch program
doesn't create a new environment, or doesn't keep the environment variables
set by vsvars32.bat.

Suggestions Welcome.

Rob

P.S.  The mess of IF code to detect the MSVC version and use the
environment variable has not been vetted and is mostly a guess at this
point.  From all the googling I could do, it is probably closeish to right.

P.P.S.  vsvarsall.bat Is special because it lets you set 32/64/arm target
and also 32/64 host environments.  I would like to support 32/64 target,
but you can't set target without knowing the host environment.  Is there a
CMake way to detect whether the Visual Studio host environment is 32/64 bit?




On Thu, Jan 9, 2014 at 10:48 AM, Rob McDonald rob.a.mcdon...@gmail.com
wrote:

 Correct, this is one of the concerns that makes it more complex than just
searching for the first vcvarsall.bat you come to.

 I'd like to match up the vcvarsall to the version of visual studio
currently in use by CMake.

 I think there are now enough pieces that I can write a CMake
'FindVSEnvironment.cmake'.  While I can't test it for a large number of
MSVC versions, I'll post it and hopefully others can help out.

 Rob


 On Thu, Jan 9, 2014 at 6:44 AM, John Drescher dresche...@gmail.com
wrote:

  Why not just write your own batch ('buildit.bat') file that does:
 
 call vcvarsall.bat
 nmake
 
  (or whatever the command to build in the VS command prompt is...)
 
  And then your command to build is:
 
 C:/full/path/to/buildit.bat
 
  It's presumably in a Windows-specific chunk of your CMakeLists anyway,
so
  that should work fairly simply.

 I think the part of problem would be figuring out what vcvarsall.bat
 to run especially if you have more than 1 version of Visual Studio.

 John


--

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

Re: [CMake] Fwd: Visual Studio command line from CMake

[Rob McDonald]

Bill,

I've scoured those examples and read the documentation many times.  I'm
also making pretty (perhaps overly) complex use of ExternalProject_Add.

I should have been more specific in my request for tips.

I have not found examples of ExternalProject driving Visual Studio projects
or nmake files.  All the common examples drive either ./configure, pure
make, or CMake setups.

Rob



On Thu, Jan 9, 2014 at 11:28 AM, Bill Hoffman bill.hoff...@kitware.comwrote:

 On 1/9/2014 2:13 PM, Rob McDonald wrote:

 Bill,

 This sounds interesting.  After FLTK, I have a couple other libraries
 that need to be packaged as an ExternalProject.

 I'd appreciate some more details or a link to an example if you have one.

 Thanks,

 See Dave Cole's message at the end:
 http://cmake.3232098.n2.nabble.com/ExternalProjects-
 Add-limitations-td7586432.html

 Also, here:

 http://www.kitware.com/media/html/BuildingExternalProjectsWithCM
 ake2.8.html

 --
 Bill Hoffman
 Kitware, Inc.
 28 Corporate Drive
 Clifton Park, NY 12065
 bill.hoff...@kitware.com
 http://www.kitware.com
 518 881-4905 (Direct)
 518 371-3971 x105
 Fax (518) 371-4573

--

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Fwd: Visual Studio command line from CMake

[Rob McDonald]

All,

My FLTK EmbeddedProject woes are solved.  As it turns out, the path of
least resistance was the one I hadn't tried

While the FLKT CMake files were indeed out of date, they weren't that bad.
 Fixing them was by far the best solution.

I have a few more libraries for my project, but hopefully they'll go more
smoothly.

Best,

Rob
--

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://www.cmake.org/mailman/listinfo/cmake

[CMake] Visual Studio command line from CMake

[Rob McDonald]

Short version:

Does anyone have an elegant way to launch the visual studio command line
from within CMake?

James Bigler asked essentially this question back in March of 2011.  David
responded with a link to a Blog entry, but I haven't figured out how to
translate that into something that works.

The 'vcvarsall.bat' program that comes with Visual Studio will launch the
command line with the full environment set.

Once I find vcvarsall, I then need to launch something in it -- and pass
parameters to that thing.  All from within ExternalProject_Add.  For now,
one step at a time...

Long version:

I'm trying to encapsulate the build of FLTK as an ExternalProject in CMake.
 One way or the other, it needs to work for Visual Studio on Windows, and
gcc and llvm on Linux/MacOS.

Although FLTK has a CMake build system, it is currently unmaintained
(broken on at least some platforms), and none of the core FLTK developers
use it, so I don't see this situation improving.

I've got a ./configure based system working for Linux/MacOS.

One of the FLTK developers maintains an unofficial Makefile setup for
FLKT/Visual Studio that must be run from the Visual Studio command prompt.
 Hence my question...

http://seriss.com/people/erco/fltk/tmp/vsnet-makefiles.0.85.zip

Thanks for any help,

Rob
--

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Visual Studio command line from CMake

[Rob McDonald]

Very sorry for not replying to the list, I certainly meant to.  I didn't
mean to impose my problem on you -- and I was hoping that by flushing my
example out more fully, more people may be able to help out.  I will go
back and forward that response/question so people don't have to dig it out
of this chain.


On Wed, Jan 8, 2014 at 8:49 PM, J Decker d3c...@gmail.com wrote:

 (you should have replied that back to the list)
 My uppermost project is a project chain of independant source parts in
 my tree... the topmost project writes out makeit.bat configuration
 files with a cmake ... command that has all the required options and
 switches (I'll append at end) and then the appropriate build command
 for the cmake environment...

 but then from the commandline I just do cmake --build . in the
 directory... (or makeit.bat)

 maybe you need something like... (I took the build command (and cmake
 command for the configuration of it)

   if( MSVC )

 if( NOT EXISTS ${BUILD}/${SOLUTION}.sln )

   FILE( WRITE ${BUILD}/${SOLUTION}.sln )

 endif()

 if( ${CMAKE_MAKE_PROGRAM} MATCHES .*[Mm][Ss][Bb]uild.* )

  build_command( BUILD_COMMAND CONFIGURATION ${CMAKE_BUILD_TYPE}
 PROJECT_NAME ${SOLUTION} TARGET INSTALL )

   SET( MORE_ARGS /m:4 /v:m )

 else()

build_command( BUILD_COMMAND CONFIGURATION ${CMAKE_BUILD_TYPE}
 PROJECT_NAME ${SOLUTION} TARGET INSTALL.vcxproj )

 endif()

 SEPARATE_ARGUMENTS( BUILD_COMMAND WINDOWS_COMMAND ${BUILD_COMMAND} )

 SET( BUILD_COMMAND ${BUILD_COMMAND} ${MORE_ARGS} )

 SET( ADD_SOURCES  SOURCES ${BUILD}/${SOLUTION}.sln )

   else( MSVC )

 build_command( BUILD_COMMAND CONFIGURATION ${CMAKE_BUILD_TYPE}
 PROJECT_NAME ${SOLUTION} TARGET install )

 SEPARATE_ARGUMENTS( BUILD_COMMAND UNIX_COMMAND ${BUILD_COMMAND} )

   endif( MSVC )




  Then later I had to -

   string (REPLACE ;   FAKE_BUILD_COMMAND ${BUILD_COMMAND})
   FILE( APPEND ${BUILD}/${SCRIPTNAME} ${FAKE_BUILD_COMMAND} )

 I was writing the invokation to a file...  I don't know if the
 expansion from ';' to space is required if it's used with
 execute_process

 EXECUTE_PROCESS(COMMAND ${BUILD_COMMAND} )


  --- sample makeit.bat ---
 c:/tools/unix/cmake/bin/cmake.exe -G Visual Studio 11 -T v110_xp
  M:/sack/cmake_all/.. -DCMAKE_BUILD_TYPE=debug

 -DCMAKE_INSTALL_PREFIX=C:/general/build/vs11-x86.monolithic/sack/debug_solution/../debug_out/core
 -DBUILD_MONOLITHIC=1 -D__NO_ODBC__= -DNEED_FREETYPE=1 -DNEED_JPEG=1
 -DNEED_PNG=1 -DNEED_ZLIB=1 -DBULLET_SOURCE=M:/bullet/source

 C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
 INSTALL.vcxproj /p:Configuration=debug /p:VisualStudioVersion=11.0
 /m:4 /v:m
  --- end sample makeit.bat ---


 And Please understand I may be totally missing your point...

 When is it that you want to run msbuild?


As far as I know, I never run msbuild.

The command line Makefile driven system Erco put together (the non-FLTK
download link from before) is a one-stop shop.

By running 'gmake.bat', it configures the program and then launches the
build via gmake.exe.  I do not believe it ever creates a *.prj or *.sln
file.  I do not believe it ever runs msbuild.  I believe gmake works with
the Makefile to call the compiler via 'cl' directly.

However, I haven't dug super deep into Erco's magic.

Rob




 On Wed, Jan 8, 2014 at 7:50 PM, Rob McDonald rob.a.mcdon...@gmail.com
 wrote:
  Thanks for the tip, but that hasn't been very helpful to me.  Perhaps I'm
  not doing it right.  Here is a bit of CMake code so the conversation can
 be
  more concrete...
 
  You'll need these two files...
 
 
 http://www.fltk.org/software.php?VERSION=1.3.2FILE=fltk/1.3.2/fltk-1.3.2-source.tar.gz
  http://seriss.com/people/erco/fltk/tmp/vsnet-makefiles.0.85.zip
 
  Place them in the same directory with the following in the CMakeLists.txt
 
  CMAKE_MINIMUM_REQUIRED( VERSION 2.8 )
 
  INCLUDE( ExternalProject )
 
  SET( VS_MAKEFILE_ZIP vsnet-makefiles.0.85.zip )
 
  ExternalProject_Add( FLTK
  URL ${CMAKE_SOURCE_DIR}/fltk-1.3.2-source.tar
  UPDATE_COMMAND
  ${CMAKE_COMMAND} -E copy_if_different
  ${CMAKE_SOURCE_DIR}/${VS_MAKEFILE_ZIP}
  SOURCE_DIR/${VS_MAKEFILE_ZIP}
  COMMAND
  ${CMAKE_COMMAND} -E tar -xzf SOURCE_DIR/${VS_MAKEFILE_ZIP}
 
  PATCH_COMMAND 
  CONFIGURE_COMMAND 
  BUILD_COMMAND 
  INSTALL_COMMAND 
  )
 
 
  To build this manually, first, unzip both files into the same directory.
  Then, launch the Visual Studio Command Prompt, usually accessed via the
  VS/vcvarsall.bat program included with Visual Studio.
 
  Once both files are unzipped into the same directory, and you are in the
 VS
  prompt environment, you can build FLTK using the batch program
 'gmake.bat'.
 
  For better or worse, it prompts the user to input for Debug or Release,
 and
  then for Verbose or Quiet.  If you make a simple text file with the
 entries
  one per line...
 
  *** input.txt
  R
  Q
  ***
 
  You can feed that to the batch program thusly
 
  gmake

[CMake] Fwd: Visual Studio command line from CMake

[Rob McDonald]

Thanks for the tip, but that hasn't been very helpful to me.  Perhaps I'm
not doing it right.  Here is a bit of CMake code so the conversation can be
more concrete.  Perhaps someone on list can try it out...

You'll need these two files...

http://www.fltk.org/software.php?VERSION=1.3.2FILE=fltk/1.3.2/fltk-1.3.2-source.tar.gz
http://seriss.com/people/erco/fltk/tmp/vsnet-makefiles.0.85.zip

Place them in the same directory with the following in the CMakeLists.txt

CMAKE_MINIMUM_REQUIRED( VERSION 2.8 )

INCLUDE( ExternalProject )

SET( VS_MAKEFILE_ZIP vsnet-makefiles.0.85.zip )

ExternalProject_Add( FLTK
URL ${CMAKE_SOURCE_DIR}/fltk-1.3.2-source.tar
UPDATE_COMMAND
 ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_SOURCE_DIR}/${VS_MAKEFILE_ZIP}
SOURCE_DIR/${VS_MAKEFILE_ZIP}
 COMMAND
${CMAKE_COMMAND} -E tar -xzf SOURCE_DIR/${VS_MAKEFILE_ZIP}

 PATCH_COMMAND 
CONFIGURE_COMMAND 
BUILD_COMMAND 
 INSTALL_COMMAND 
)


To build this manually, first, unzip both files into the same directory.
 Then, launch the Visual Studio Command Prompt, usually accessed via
the VS/vcvarsall.bat
program included with Visual Studio.

Once both files are unzipped into the same directory, and you are in the VS
prompt environment, you can build FLTK using the batch program 'gmake.bat'.

For better or worse, it prompts the user to input for Debug or Release, and
then for Verbose or Quiet.  If you make a simple text file with the entries
one per line...

*** input.txt
R
Q
***

You can feed that to the batch program thusly

gmake  input.txt

Alternately, if you can set DEBUG=R and VERBOSE=Q environment variables to
the shell used to run 'gmake.bat', then you don't have to feed the text
file for the user-input prompts.

I tried something like the following

BUILD_COMMAND
   ${CMAKE_COMMAND} --build SOURCE_DIR -- gmake

But, it didn't seem to do anything useful

Rob


On Wed, Jan 8, 2014 at 5:31 PM, J Decker d3c...@gmail.com wrote:

 cmake --build

 On Wed, Jan 8, 2014 at 3:53 PM, Rob McDonald rob.a.mcdon...@gmail.com
 wrote:
  Short version:
 
  Does anyone have an elegant way to launch the visual studio command line
  from within CMake?
 
  James Bigler asked essentially this question back in March of 2011.
  David
  responded with a link to a Blog entry, but I haven't figured out how to
  translate that into something that works.
 
  The 'vcvarsall.bat' program that comes with Visual Studio will launch the
  command line with the full environment set.
 
  Once I find vcvarsall, I then need to launch something in it -- and pass
  parameters to that thing.  All from within ExternalProject_Add.  For now,
  one step at a time...
 
  Long version:
 
  I'm trying to encapsulate the build of FLTK as an ExternalProject in
 CMake.
  One way or the other, it needs to work for Visual Studio on Windows, and
 gcc
  and llvm on Linux/MacOS.
 
  Although FLTK has a CMake build system, it is currently unmaintained
 (broken
  on at least some platforms), and none of the core FLTK developers use
 it, so
  I don't see this situation improving.
 
  I've got a ./configure based system working for Linux/MacOS.
 
  One of the FLTK developers maintains an unofficial Makefile setup for
  FLKT/Visual Studio that must be run from the Visual Studio command
 prompt.
  Hence my question...
 
  http://seriss.com/people/erco/fltk/tmp/vsnet-makefiles.0.85.zip
 
  Thanks for any help,
 
  Rob
 
 
 
 
  --
 
  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://www.cmake.org/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://www.cmake.org/mailman/listinfo/cmake

[CMake] ExternalProjects_Add limitations

[Rob McDonald]

All,

Thanks for all your work on CMake.  I really hate toolchain problems and
CMake makes them almost bearable.  The entire community of developers
trying to make cross platform programs would be far worse off without CMake.

My project is a big open source C++ project with lots of library
dependencies (OpenGL, GLM, GLEW, CppTest, FLTK, LibXml2, LibJPEG, soon
adding Eigen3, STEPCODE).

In the past, we've left all the dependencies up to the developer.  This
limits us to truly dedicated (compensated) high-level wizards.  Even then,
you either spend two days working out the dependencies or some other wizard
sends you a 200MB zip file of precompiled libraries.  We believe this is a
significant problem towards attracting developers.  It also precludes us
from having any control/knowledge of what versions of libraries the
developers are actually using.  Not the best things for trying to build an
open source community.

I am determined to wrestle this beast.  Here is my plan...

We will embed the dependencies in our source.  This may be through git
submodules, direct includsion, CMake ExternalProject_Add, or a combination
thereof.

The embedded dependencies should be optional where appropriate -- for
platforms with extensive package libraries, we want to enable our program
to search for and use pre-installed libraries.

For everyone else, I believe that relying on the embedded dependencies will
be the primary mode for development.  So, we want the build environment to
'look normal' for this case.  I.e. project source files should show up in
IDEs, various make targets should be exposed.

We would like to use the library's own build files.  Whether CMake,
./configure, or something else, we presume that the project developers know
what they're doing and we don't want to second-guess them or recreate the
wheel.

We would also like to use the library's own FindXXX.cmake routines.  Some
of these are more complex than just setting one path and one library.  We'd
like to avoid recreating all of that knowledge.  This has the added
advantage that we can make our core project's CMake setup nearly
independent of how the libraries are handled.


I have something mostly working based on ExternalProject_Add.  Following
the advice online, I've used it for _everything_, all the big libraries and
our main project.

I've worked around the problem of the top level project not tracking
file-level changes of the nested projects using a 'ForceBuild' macro for
just our main project.

However, this approach does not make the development environment 'look
normal' to Visual Studio.  None of the project source appears, none of the
build targets appear (doc, package install, test, etc).  Is there any way
to make the 'Everything is an ExternalProject' approach 'look normal' to
Visual Studio and other IDE's?

I have since tried moving to a two-class system, where my main project is
not ExternalProject_Add'ed, but the big dependencies are.  This of course
runs into the problem where the libraries are not built when the
FindXXX.cmake modules go looking for them, the configure phase fails and
nothing ever gets built.

I believe the solution to this is prolific use of ADD_DEPENDENCIES, but I
also believe that solution requires setting XXX_INCLUDE_DIR and
XXX_LIBRARIES manually rather than through FindXXX.cmake.  That seems
fragile and difficult to me.


I'd like a way to force the main project to build the ExternalProjects
before even continuing with the CMake.  Perhaps a conditional...

ExternalProject_Add( libA  )
ExternalProject_Add( libB  )
ExternalProject_Add( libC  )


IF ( ExternalProjectsOutOfDate )
  ExternalProject_Add( libcheck
 DEPENDS libA libB libC
 URL 
 UPDATE_COMMAND 
 CONFIGURE_COMMAND 
 BUILD_COMMAND 
 INSTALL_COMMAND 
   )
   # Touch CMakeLists.txt to force re-run of CMake on next build.
ELSE ( ExternalProjectsOutOfDate )

# Continue on merry way for 'normal' project.
# ...

ENDIF ( ExternalProjectsOutOfDate )
# EOF

However, I don't know how to make that conditional work, or to re-trigger
CMake as required.


I'm currently leaning towards an even more two-class decoupled system.  In
this approach, there would be two 'root' CMakeLists.txt in our project.
 One would be just for the large dependencies, the other would be for the
main project.  There would be no actual link between them.  The developer
would have to first build the dependencies, then build the main project.

Does anyone know of a project that uses this approach?  It would be nice to
have some level of communication so the main project could 'know' that the
libraries were out of date (newer version had been added to the project)
and tell the developer to go rebuild them.

Any help is appreciated,

Rob
--

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