[CMake] Help for a cmake newbie

Petr Kmoch petr.kmoch at gmail.com
Thu Feb 4 02:49:12 EST 2016


Hi Vadtec.

*The* standard CMake way of dealing with building your dependencies is the
ExternalProject module (
https://cmake.org/cmake/help/latest/module/ExternalProject.html ). It's a
huge beast, but I belive there are some examples and tutorials available
out there.

The gist is: you create a top-level, "superbuild" CMakeLists.txt file which
will contain only the uses of ExternalProject_Add, one for each dependency,
and *one for you own project as well.* The dependencies can be downloaded,
patched, builtt, installed, etc., depending on the parameters you pass to
ExternalProject_Add. They do not have to be CMake-based; when they are not,
simply provide an empty (or otherwise project-specific) CONFIGURE_COMMAND
argument.

When CMake is run on the superbuild, it generates a buildsystem such that
building it downloads, builds, installs, etc. the external projects. All of
this happens at build time, not at CMake time.

This way, you have full control over which dependencies you build in what
order, where they get installed etc. Of course, in your case with
dependency sources shipped, you don't need a download step (or perhaps
maybe just to unpack them).

Once you've successfully built the superbuild once, all the dependencies
are ready, and your own project (which you've set up as just another
external project) is configured and all its dependencies are in locations
which you've specified. Now you switch into the binary directory
corresponding to your project and no longer need to work in the superbuild
- each external project is self-contained in that it can be used directly
as well, without having to go through the superbuild.

On a very symbolic level, an external project setup can look something like
this:

root/CMakeLists.txt:
project(SuperBuild)
include(ExternalProject)

ExternalProject_Add(
  LibraryWeNeed
  PREFIX deps/LibraryWeNeed
  DOWNLOAD_COMMAND somehow_unpack
${CMAKE_CURRENT_SOURCE_DIR}/deps/LibraryWeNeed.tgz --into
${CMAKE_CURRENT_BINARY_DIR}/deps/LibraryWeNeed
  BUILD_COMMAND make whatever
  ...
)

ExternalProject_Add(
  MyProjectItself
  PREFIX mybuild
  SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src
  DEPENDS LibraryWeNeed
  CMAKE_GENERATOR ${CMAKE_GENERATOR}  # use the same generator as the
superbuild
  CMAKE_CACHE_ARGS
-DLibraryWeNeed_ROOT:PATH=${CMAKE_CURRENT_BINARY_DIR}/deps/LibraryWeNeed
  ...
)


src/CMakeLists.txt:
project(MyProject)
find_package(LibraryWeNeed PATHS ${LibraryWeNeed_ROOT})  # the root path
was passed in by the superbuild
...


To work with this, you would then do:

cd build
cmake ../root  # generates superbuild
make  # builds superbuild
cd mybuild  # go into MyProject's binary dir
make  # builds MyProject


Once more, this is all very symbolic. Please refer to documentation,
tutorials etc. to achieve the behaviour you need.

Petr



On Sun, Jan 31, 2016 at 3:42 AM, vadtec <vadtec at vadtec.net> wrote:

> Let me start by saying I consider my self a cmake newbie. I've made simple
> makefiles and simple cmake files, but anything more complicated has to this
> point eluded me. Not for a lack of trying, searching, researching, trail,
> and a great deal of error: I simply have not been able to achieve the
> things I'm after. If the sort of questions I'm asking have been answered
> elsewhere (as I'm sure they have), I apologize for asking them again. That
> being said, I realize I'm going to be asking some questions that my
> Google-Fu has failed me in answering. Forgive me my failings, but I'm at my
> witts end.
>
>
> I have a project that I'm building on Linux that has a server component
> and a client component that also needs to run on Windows. It uses several
> libraries that I want to version lock so I run into fewer issues with cross
> compiling and feature creep.
>
> The project is laid out like this:
>
> /home
>     mydir/
>         project/
>             build/
>             bundle/
>             deps/
>                 curl-7.43.0/
>                 libiconv-1.14/
>                 libpng-1.6.18/
>                 libssh2-1.6.0/
>                 openssl-1.0.2d/
>                 sqlite/
>                 tinycthread/
>                 zlib-1.2.8/
>             include/
>                 client/
>                     client.h
>                 common/
>                     config.h
>                     common_funcs.h
>                 server/
>                     server.h
>             src/
>                 client/
>                     client.c
>                 common/
>                     common_funcs.c
>                 server/
>                     server.c
>
> curl, libiconv, libpng, libssh2, and zlib are the libs I want to build and
> use both on Linux and Windows. I know all of those are available on Linux
> and I could use the system installed versions, but I want to use the same
> vesions on Windows as well. The server is only built on Linux, while the
> client needs to be built for Linux and Windows. All the libs, headers, etc
> go into the build directory, and the final "make install" puts everything
> into the bundle directory, so it can be packaged for distribution.
>
> The client needs the curl, libiconv, libpng, libssh2, openssl, and zlib
> libraries. tinycthread is compiled directly into the client, so that's not
> an issue.
>
> The server needs the curl, libiconv, libssh2, openssl, and zlib libraries.
> tinycthread and sqlie are compiled directly into the server, so that's not
> an issue.
>
> Ideally, I'd like my cmake file to build the deps that need to be built,
> build the server and client for Linux, and finally build the client for
> Windows. Yes, all from the same cmake file. I realize this will probably
> have to be done with multiple cmake files or a bash script, but that's ok.
>
> I think building the libs can be done with custom commands or targets, but
> I haven't been able to figure out how. I haven't been able to get cmake to
> use only my versions of the libs I've compiled. Some of the libs are being
> found from the system wide versions, some are coming from my directory.
>
> My main problem is getting cmake to use only my locally installed/compiled
> copies of the libs. I need those libs to live along side the binaries, and
> using the versions I compile is important.
>
> Rather than provide the CMakeLists.txt I've been using, I'd like it if
> someone could provide an example file that would compile the above
> libraries (all of which use autoconf or custom compile scripts) and the
> client and server for Linux and Windows. I'm 100% certain I am not doing
> things correctly when it comes to the layout of the CMakeLists.txt, so I'd
> like to see something fresh from someone with much more experience in build
> script creation.
>
> Any help is greatly appreciated.
>
> ------------------------------
> Vadtec
> vadtec at vadtec.net
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160204/e927fa8c/attachment-0001.html>


More information about the CMake mailing list