coding style for modules

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

coding style for modules

Dave Milter
Hello,

If there is some libfoo that I want to use in my project,
and this libfoo has it's own CMakeLists.txt I have 3 options to deal
with such external dependency:

a) Treat it like every other external dependency and write cmake code
  like FindLibFoo.cmake to find libfoo on file system.

b)Include this project as git submodule and use ExternalProject to
invoke `cmake` and `cmake --build`

c)Include this project as git submodule and use add_subdirectory(libfoo)


Variant "c" has advantages that potentially in this case it is
possible to have almost the same compiler flags for libfoo and main
project, which may give the most
robust solution in case of usage visual studio (release/debug/multi
thread/single thread CRT problems), plus it is simplify a lot cross
compilation.

But usually "libfoo" CMakeLists.txt looks like this:

```
cmake_minimum_required(VERSION 3.10)

#configure many things that important for standalone
#project, but not requires for project as part of another project
#for example in case of gcc we add some special flags like -Wall
-Wextra -pedantic and so on

add_library(foo SHARED sources)
```

and part between `cmake_minimum_required` and `add_library` is useless
and sometime prevent cross compilation and usage of the same compiler flags.

So question how should I organize CMakeListst.txt of libfoo help deals with "c"?

Should I move all specific for standalone project code to:

if(CMAKE_SOURCE_DIR STREQUAL PROJECT_SOURCE_DIR)
# i am standalone
endif()

or may be I should use some other tricks?
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: coding style for modules

Don Hinton
I normally see it like this:

if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
  project(foo)
# ...
endif()

hth...
don

On Wed, Jan 3, 2018 at 6:09 PM, Dave Milter <[hidden email]> wrote:
Hello,

If there is some libfoo that I want to use in my project,
and this libfoo has it's own CMakeLists.txt I have 3 options to deal
with such external dependency:

a) Treat it like every other external dependency and write cmake code
  like FindLibFoo.cmake to find libfoo on file system.

b)Include this project as git submodule and use ExternalProject to
invoke `cmake` and `cmake --build`

c)Include this project as git submodule and use add_subdirectory(libfoo)


Variant "c" has advantages that potentially in this case it is
possible to have almost the same compiler flags for libfoo and main
project, which may give the most
robust solution in case of usage visual studio (release/debug/multi
thread/single thread CRT problems), plus it is simplify a lot cross
compilation.

But usually "libfoo" CMakeLists.txt looks like this:

```
cmake_minimum_required(VERSION 3.10)

#configure many things that important for standalone
#project, but not requires for project as part of another project
#for example in case of gcc we add some special flags like -Wall
-Wextra -pedantic and so on

add_library(foo SHARED sources)
```

and part between `cmake_minimum_required` and `add_library` is useless
and sometime prevent cross compilation and usage of the same compiler flags.

So question how should I organize CMakeListst.txt of libfoo help deals with "c"?

Should I move all specific for standalone project code to:

if(CMAKE_SOURCE_DIR STREQUAL PROJECT_SOURCE_DIR)
# i am standalone
endif()

or may be I should use some other tricks?
--

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:
https://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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: coding style for modules

Alan W. Irwin
In reply to this post by Dave Milter
On 2018-01-04 05:09+0300 Dave Milter wrote:

> Hello,
>
> If there is some libfoo that I want to use in my project,
> and this libfoo has it's own CMakeLists.txt I have 3 options to deal
> with such external dependency:
>
> a) Treat it like every other external dependency and write cmake code
>  like FindLibFoo.cmake to find libfoo on file system.
>
> b)Include this project as git submodule and use ExternalProject to
> invoke `cmake` and `cmake --build`
>
> c)Include this project as git submodule and use add_subdirectory(libfoo)

Or

  d) Use a config-file package approach (the preferred modern
  alternative to the find-file package approach used in (a)).  See
  <https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html>
  for details concerning config-file packages. Of course, this option
  assumes that external software's CMake-based build system has been
  developed to the point of creating a config-file package. However, if
  it has a CMake-based build system already that is just lacking such a
  package, it is straightforward to implement such a package (from my
  experience doing that for several different projects and also from
  the above URL).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: coding style for modules

Alexander Neundorf-3
In reply to this post by Dave Milter
On 2018 M01 4, Thu 05:09:54 CET Dave Milter wrote:
> Hello,
>
> If there is some libfoo that I want to use in my project,
> and this libfoo has it's own CMakeLists.txt I have 3 options to deal
> with such external dependency:
>
> a) Treat it like every other external dependency and write cmake code
>   like FindLibFoo.cmake to find libfoo on file system.

This would be a clean solution if you don't want to build libfoo as part of
your project.

> b)Include this project as git submodule and use ExternalProject to
> invoke `cmake` and `cmake --build`

This would be a clean solution if you want to build libfoo as part of yur
project.

>
> c)Include this project as git submodule and use add_subdirectory(libfoo)

the "parent" project will/can influence the behaviour of libfoo then, I would
not recommend this.

Or use d) as Alan suggests.

Alex

--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: coding style for modules

Craig Scott-3


On Fri, Jan 5, 2018 at 8:09 AM, Alexander Neundorf <[hidden email]> wrote:
On 2018 M01 4, Thu 05:09:54 CET Dave Milter wrote:
>
> c)Include this project as git submodule and use add_subdirectory(libfoo)

the "parent" project will/can influence the behaviour of libfoo then, I would
not recommend this.

It depends on the situation, sometimes you explicitly want this. An advantage of this approach is that libfoo will then be built with the same set of flags as the main build (apart from those flags it modifies itself). It also plays nicely with IDE projects because they will typically see all the sources of libfoo as well as the main project. You can also end up building just the targets from libfoo that you need instead of building everything as you would if it was external. The new FetchContent module (on master, not yet in a public release) makes this approach particularly easy.

--
Craig Scott
Melbourne, Australia

--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: coding style for modules

Dave Milter
In reply to this post by Alexander Neundorf-3
On Fri, Jan 5, 2018 at 12:09 AM, Alexander Neundorf
<[hidden email]> wrote:>
>> b)Include this project as git submodule and use ExternalProject to
>> invoke `cmake` and `cmake --build`
>
> This would be a clean solution if you want to build libfoo as part of yur
> project.
>

Thank you for answer, but how handle cross compilation in this case?
For example I invoke `cmake
-DCMAKE_TOOLCHAIN_FILE=~/Android/Sdk/ndk-bundle/build/cmake/android.toolchain.cmake`
for master project.
Does `cmake` automatically add proper ` -DCMAKE_TOOLCHAIN_FILE=`
option into `cmake` invocation in ExternalProject?
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: coding style for modules

Stephen Orso
In reply to this post by Dave Milter

On Fri, 5 Jan 2018 18:16:08 +0300 Dave Milter <[hidden email]> wrote:

> b)Include this project as git submodule and use ExternalProject to
>>> invoke `cmake` and `cmake --build`
>> This would be a clean solution if you want to build libfoo as part of yur
>> project.
>>
> Thank you for answer, but how handle cross compilation in this case?
> For example I invoke `cmake
> -DCMAKE_TOOLCHAIN_FILE=~/Android/Sdk/ndk-bundle/build/cmake/android.toolchain.cmake`
> for master project.
> Does `cmake` automatically add proper ` -DCMAKE_TOOLCHAIN_FILE=`
> option into `cmake` invocation in ExternalProject?
I haven't gotten to cross compilation yet, but my CMake project uses
externalproject_add for several modules.  I want them built using the
same generator and the same configuration type as the parent (consuming)
project.  Some of the allowed generators for this project are
multi-configuration,
and some are not.

I use the following CMake code:

<CMake code>

# WINTARGET is needed by the configure-time external package build
# and for the creation of the externalproject_add() target.
if( NOT ${WINTARGET} STREQUAL "" )
     set( __wintarget -DWINTARGET=${WINTARGET} )
endif( )

# If we are configuring using a single-configuration generator,
# the configuration name is needed by the configure-time external
# package build and for the creation of the externalproject_add()
# target.
if( "${CMAKE_CONFIGURATION_TYPES}" STREQUAL "" )
     set( __build_type "-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}" )
endif( )

if( NOT "${CMAKE_GENERATOR_PLATFORM}" STREQUAL "" )
     set(__platform -A ${CMAKE_GENERATOR_PLATFORM} )
endif( )
if( NOT "${CMAKE_GENERATOR_TOOLSET}" STREQUAL "" )
     set(__toolset -T ${CMAKE_GENERATOR_TOOLSET} )
endif( )

# When building a static library using externalproject_add() and
# using Ninja for the build tool, we must include the library name
# in the BUILD BYPRODUCTS option of externalproject_add(). See the
# discussion at https://cmake.org/pipermail/cmake/2015-April/060233.html.
# This issue applies only to SoftFloat-3a at the moment because it
# is the only static library built and used by this project.

# Retrieve the full path name of the static library for the current
# configuration from the imported target.  This is relatively simple
# because Ninja is a single-configuration build tool, so we know
# which configuration should be retrieved from the target at
# configure time.

if( "${CMAKE_GENERATOR}" STREQUAL "Ninja" )
     if( "${pkgid}" MATCHES "^[Ss]3[Ff][Hh]$" )
         string( TOUPPER "${CMAKE_BUILD_TYPE}" __build_byproducts )
         get_target_property(
                 __build_byproducts
                 SoftFloat
                 IMPORTED_LOCATION_${__build_byproducts}
                 )
         message( "Build type ${CMAKE_BUILD_TYPE}, Setting
BUILD_BYPRODUCTS to ${__build_byproducts}" )
     endif( )
endif( )

# externalproject_add() does not expose a git depth option, so we
# must download the entire repository.  Oh well...maybe someday.
# Note that "<INSTALL_DIR>" below is not a typo'd generator
# expression.

externalproject_add( ${pkg}
         PREFIX            ${__pkg_prefix}
         SOURCE_DIR        ${__pkg_prefix}/pkgsrc
         BINARY_DIR        ${__pkg_prefix}/build
         INSTALL_DIR       ${__pkg_prefix}/install
         GIT_REPOSITORY    ${pkgurl}
         GIT_TAG           ${pkgbranch}
         CMAKE_GENERATOR           ${CMAKE_GENERATOR}
         CMAKE_GENERATOR_TOOLSET ${CMAKE_GENERATOR_TOOLSET}
         CMAKE_GENERATOR_PLATFORM ${CMAKE_GENERATOR_PLATFORM}
         CMAKE_ARGS
                 ${__wintarget}
                 ${__build_type}
-D${__CMAKE}INSTALL_PREFIX=<INSTALL_DIR>
                 -DCMAKE_REQUIRED_QUIET=TRUE
         BUILD_BYPRODUCTS  ${__build_byproducts}
         PATCH_COMMAND     ""        # No patches
         UPDATE_COMMAND    ""        # No updates
         INSTALL_COMMAND   ""        # ..and no install.
     )

</CMake code>


I expect it would not be difficult to add the toolchain file in the same
way.

--
Best Regards,
Steve Orso

--

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