[CMake] Help for a cmake newbie

Fri Feb 5 13:57:13 EST 2016

Petr,

Thanks for the info. I'm working on getting the builds to work exactly like I want for both native *nix and cross-compile Windows builds, so it's a learning process. I do appreciate your info.

Vadtecvadtec at vadtec.net

---- On Thu, 04 Feb 2016 01:49:12 -0600 Petr Kmoch <petr.kmoch at gmail.com> wrote ---- 

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.

Vadtecvadtec 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/20160205/f754e7fd/attachment.html>