Add more cmake options

[PierreZ]

I'm working on packaging FoundationDB for Exherbo, an source based Linux distribution. My goal is to create a package with multiples options(similar to USE flags in Gentoo), to allow developers to carefully choose what they need, for example:

• using the client option will build the C API,
• using the server option will build fdb{server,monitor,backup}),
• using the systemd option will a systemd service,
• using the java-bindings option will build the java-bindings,
• and so on...

Currently, when pulling the master branch, almost everything is build by default, resulting in a lot of compile time and needed dependencies why may not be necessary for the end user. The only dependencies that can be removed are:

• RocksDB through the -DSSD_ROCKSDB_EXPERIMENTAL flag,
• TLS.

Adding more cmake options will allow users to carefully select what they want to build. This will also lower compile time in certain cases and ease package creation.

I was thinking adding options to:

• the bindings,
• fdbclient,
• fdbserver,
• fdbcli,
• fdbmonitor/fdbservice,
• fdbbackup

Most of these bindings targets already have boolean, which can be easily exported as cmake options. I would like to do the same for binaries as well, to allow building only the C API for example.

The new options will have TRUE as a default for compatibility with the current builds.

Are you interested in such a contribution? May it also target the release-7.0 branch?

[rajivr]

My goal is to create a package with multiples options(similar to USE flags in Gentoo), to allow developers to carefully choose what they need, for example:

* using the `client` option will build the `C API`,

* using the `server` option will build `fdb{server,monitor,backup}`),

* using the `systemd` option will a systemd service,

* using the `java-bindings` option will build the java-bindings,

* and so on...

@PierreZ, perhaps you could please consider splitting fdbmonitor into separate build option.

I am very new to FoundationDB. For my upcoming FDB learning, I recently ended up creating Nix derivations to repackage FDB binaries based on the information from these links - link 1, link 2, link 3, link 4.

You can think of Nix derivations as "packages" in traditional distro, but multiple versions of derivations can be installed without any conflicts. Following is the organization I used

1. fdb-monitor-6.3.15

   Consisting of fdbmonitor binary.

2. fdb-cli-tools-6.3.15

   Consisting of fdbbackup, fdbcli, fdbdr, fdbrestore binaries.

3. fdb-daemons-6.3.15

   Consisting of backup_agent, dr_agent, fdbserver.

4. fdb-client-lib-6.3.15

   Consisting of libfdb_c_6.3.15.so binary.

[sfc-gh-mpilman]

I don't quite understand what the request here is...

For bindings, you can set a variable. For example, if you don't want to build the go bindings, you can set GO_EXECUTABLE to GO_EXECUTABLE-NOTFOUND. I agree that this is a bit ugly -- having options for these would probably be a good idea.

But I don't see a good reason to have options for fdbcli etc. If you only want to build fdmonitor you can do that by running ninja fdbmonitor. Or am I misunderstanding something?

[PierreZ]

@PierreZ, perhaps you could please consider splitting fdbmonitor into separate build option.

I really like how you splitted from a user point-of-view, thanks for the idea! That might be overkill for our usecase though.

But I don't see a good reason to have options for fdbcli etc.

After playing for a day around these options, I agree with you.

My main goal is to have a package that can be installed on a "layer" host or on a "cluster" host, which means split the fdbclient and the rest. As I started to split things up, I ended up with some dependencies issues, which I "resolved" by splitting everything as options, so that the end-user can choose what we want:

# for layer hosts
dev-db/foundationdb client

# for cluster hosts
dev-db/foundationdb client cli server backup monitor

But, as you mentionned, having so much options is creating many issues:

• how the user knows that the option cli needs client?
• what if he's not choosing an option?
• how cmake install or cpack will behave with an untested matrix of options?
• how to handle dependencies properly (is it relevant to build only fdbmonitor without an fdbserver?)
• cmake complexity with if everywhere,
• many other issues I'm sure I can't see yet :stuck_out_tongue:

If you only want to build fdmonitor you can do that by running ninja fdbmonitor. Or am I misunderstanding something?

That was my first idea :smile: Turns-out, source-based distribution are oftenly exposing cmake wrappers where it is common to bind a flag/option to cmake options. For example, in my case:

# defaults
CMAKE_SRC_CONFIGURE_PARAMS=(
    -DSSD_ROCKSDB_EXPERIMENTAL:BOOL=FALSE
    -DBUILD_JAVA_BINDING:BOOL=FALSE
    -DBUILD_RUBY_BINDING:BOOL=FALSE
    -DBUILD_PYTHON_BINDING:BOOL=FALSE
    -DBUILD_GO_BINDING:BOOL=FALSE
)

# dynamic part according to the option the user chose
CMAKE_SRC_CONFIGURE_OPTION_BUILDS=(
    'client FDBCLIENT'
    'server FDBSERVER'
    'monitor FDBMONITOR'
    'backup FDBBACKUP'
    'doc DOCUMENTATION'
)

This will inject the right -DBUILD_ flags according to which option I chose, without constructing the right ninja command by hand, which is convenient.

For bindings, you can set a variable. For example, if you don't want to build the go bindings, you can set GO_EXECUTABLE to GO_EXECUTABLE-NOTFOUND. I agree that this is a bit ugly -- having options for these would probably be a good idea.

This will simplify packaging :+1: If that's ok for you, I will push a PR to add options to bindings.

On our side, we will start by building everything except the bindings, and maybe in the future, we could discuss on how we could allow only build/install/cpack the fdbclient. Maybe you have some thoughts about this @sfc-gh-mpilman?