[CMake] Complicated dependency handling between linux & windows

[Robert Dailey]

On Mon, Jun 10, 2013 at 12:30 PM, David Cole <dlrdave at aol.com> wrote:
>> That's more philosophical advice than practical.
>
> Hence the smiley face. Although, in reality it’s practical, too.

Don't worry, I caught your humor :)

>> It's unfortunately impossible sometimes to eliminate
>> dependencies.
>
> I understand that.
>
>
>> This is one area CMake
>> should handle well.
>> I'm a bit surprised that this is so difficult.
> I’m sure ideas on how to “handle it well” would be welcome for discussion
> here. It’s a difficult task, especially when the source code is not
> available for some of your dependencies. And when the binary distributions
> that are available might have some mismatch for the compiler you’re using.
>
> It’s a huge problem, with no easy solution in sight.

I completely understand. I don't want to just come here to complain
with no ideas. There is a simpler way to think of this problem,
though.

Let's say a project I'm building in CMake depends on 3 libraries: A, B
and C. Let's further say that A and B are in the distro's package
manager, but C is not. I have to build C myself and host it somewhere.
Pulling down A and B from the package manager is easy enough. We could
do it by hand or extend CMake to support various package managers and
it would invoke it for us. However, we have to build C ourselves and
place it somewhere. Maybe we want to submit it to the package system
and wait for it to be approved and then pull it down through normal
means after some time. Or perhaps for other reasons, we instead host
it on an FTP server somewhere as a ZIP and have it downloaded,
extracted, and included by CMake.

The first step obviously is finding a uniform, platform agnostic
system for retrieving dependencies. Perhaps instead of making CMake
responsible for this, you could write a brand new product called
CPackage or something. This would essentially provide a complete
solution to package and dependency handling. You could have it
integrate and behave differently per configuration and also per
platform. For example, on Linux you can configure CPackage to
integrate with the native package manager and also your custom
FTP/HTTP site for packages.

CPackage would impose certain restrictions on custom repositories,
such as naming, pathing, versioning, archive format, etc.

CMake can invoke CPackage through probably CMake scripts as custom
commands or something, or maybe add support natively through some C++
feature in CMake to interact with it.

One thing I have setup on my CMake script framework on Windows is an
alias system. During configure, I tell CMake where my package
repository root is on a windows share. Inside of this repository,
third party libraries are listed in a consistent structure. I have a
manifest script where I list all of the supported libraries. Each one
listed will be downloaded, extracted, and its include directories,
library directories, and binary file locations are all stored and
mapped to an alias. The manifest need not list every library in the
repository. Only those we care about.

For example, let's say I have a library "zlib" in the repository. In
my manifest, I mention it like this:

name (alias; also maps to archive filename on the repository, i.e.
zlib.zip): zlib
version: 1.2.3