Re: [CMake] Help for a cmake newbie

[vadtec]

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.

vadtecvad...@vadtec.net



 On Thu, 04 Feb 2016 01:49:12 -0600 Petr Kmoch petr.km...@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 vad...@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 

Re: [CMake] Help for a cmake newbie

[Petr Kmoch]

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  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 

Re: [CMake] Help for a cmake newbie

[Michael Surette]

On 30/01/16 09:42 PM, vadtec 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.
...
> Any help is greatly appreciated.
>
> 
> Vadtec
> vad...@vadtec.net
>
>
Check out how it's done with FLTK at fltk.org.

We put each dependency in its own folder with its own CMakeLists.txt 
then do an add_subdirectory for each. The add_subdirectory calls are 
dependent on whether that particular library is available as a system 
library and if so which you want to build with.


I'm sure you could adapt this to your purpose.

Mike


--

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] Help for a cmake newbie

[Cristian Adam]

On 31-Jan-16 03:42, vadtec wrote:


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.




Have a look at hunter  – 
Cross-platform package manager for C++ (based on CMake ExternalProject).


Hunter has CMake versions for:

 * libpng 
 * libssh2 
 * zlib 

Curl  has CMake support by itself. The 
only library missing is libiconv. It seems that
LuaDist project has added  a CMake build here 
.


You could either take all the libraries and include in your project or 
open hunter tickets. 


Cheers,
Cristian.

-- 

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] Help for a cmake newbie

[Tamás Kenéz]

Vadtec,

> 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.

I'll answer the question of finding the libraries and not the building
problem. We (in my company) are facing similar problems. This is the
workflow which has been working for us:

1. we make sure that all 3rdparty dependencies can be built with CMake and
install a config-module

Note that the "can be built with CMake" needs to be interpreted loosely:

- some 3rdparty libs already provide CMake builds which can be used as is.
In case of anything is missing (config-module) we fork and modify
- when a 3rdparty lib uses autotools we rewrite its build system in CMake
for windows compatibility
- in case the lib's build system is too complex we just wrap it in a CMake
build which launches autotools and also installs a config-module
- when only the binaries of the 3rdparty lib are available we create a
CMakeLists for the lib which detects the platform, installs the required
binaries and config-modules

In any case we end up having a project that can be built with cmake command
lines and installs a proper config-module.

2. For these 3rdparty libs we don't use the find-modules distributed with
CMake. We Set the CMAKE_PREFIX_PATH to the install prefix where we
installed our 3rdparty deps to make sure only those will be found by our
own projects.

On Sun, Jan 31, 2016 at 9:40 AM, Cristian Adam 
wrote:

> On 31-Jan-16 03:42, vadtec wrote:
>
>
> 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.
>
>
> Have a look at hunter  – Cross-platform
> package manager for C++ (based on CMake ExternalProject).
>
> Hunter has CMake versions for:
>
>- libpng 
>- libssh2 
>- zlib 
>
> Curl  has CMake support by itself. The
> only library missing is libiconv. It seems that
> LuaDist project has added  a CMake build here
> .
>
> You could either take all the libraries and include in your project or
> open hunter tickets. 
>
> Cheers,
> Cristian.
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Help for a cmake newbie

[Elizabeth Fischer]

I generally use one CMake build for compiling a single project.  Your
dependencies should be built separately from your main program.  Ways to do
this:

1. Try EasyBuild or Spack.  The only reason I wouldn't recommend them is
I'm not sure if they've ever been run on Windows.  But that doesn't mean it
wouldn't work.

2. Figure out how to compile all your prerequisites, and put them into a
single install tree.

Either way, it's unlikely that you'll be able to build the projects exactly
the same on the two systems.  Your goal should be a script that builds and
install the prerequisites in an appropriate way, taking into account system
differences.

-- Elizabeth


On Sat, Jan 30, 2016 at 9:42 PM, vadtec  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
> vad...@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