=== WHAT IS THIS?

* quickly build the entire Osmocom core network stack from source, with a
  generated top-level makefile (see the rest of this README file below).

* quickly configure, launch and tear down an entire Osmocom core network on
  your box (see net/README).


=== Quick Start

sudo apt install \
  build-essential gcc g++ make automake autoconf libtool pkg-config \
  libtalloc-dev libpcsclite-dev libortp-dev libsctp-dev libssl-dev libdbi-dev \
  libdbd-sqlite3 libsqlite3-dev libpcap-dev libc-ares-dev libgnutls28-dev \
  libsctp-dev sqlite3

./gen_makefile.py 3G+2G.deps default.opts iu.opts -I -m make

cd make
make

- 'make' will ask for sudo password to run 'make install' and 'ldconfig'.
  To run non-interactively:

  - 'make install':
    chown $USER: /usr/local
    Then call gen_makefile.py once without the -I option

  - 'ldconfig':
    echo "$USER  ALL= NOPASSWD: /sbin/ldconfig" > /etc/sudoers.d/ldconfig


=== gen_makefile.py

This provides a set of top-level makefiles to build variants of the Osmocom
source trees. It is inteded for the core network components and related
projects, but works generically.

The idea is to have all your Osmocom git clones in ./src, while keeping one or
more separate build trees in ./make-*.

Run ./gen_makefile.py with a choice of projects (2G only or also 3G?)
and a choice of configure options.


Examples:

Full 2G and 3G support:

  ./gen_makefile.py 3G+2G.deps default.opts iu.opts  -m make
  cd make
  make

2G only, and a custom dir name of 'make-2G':

  ./gen_makefile.py 2G.deps default.opts -m make-2G
  cd make-2G
  make

If you make modifications in one of the source trees, this Makefile will pick
it up, rebuild the project and also rebuild all dependencies (according to the
*.deps file the Makefile was generated from).

If you modify the *.deps or *.opts file, you can easily run 'make regen' in a
make-* subdir to regenerate the Makefile from the same files.

In your make-* subdir there are empty status files that are touched for every
completed make target. From these, 'make' can detect what needs to be rebuilt.
You can manually remove them to force a rebuild of a specific target.

For example, if you 'rm .make.libosmocore.autoconf', libosmocore and all
projects depending on libosmocore will be rebuilt from scratch.

For more details on the *.opts and *.deps syntax, read the docs at the top of
./gen_makefile.py.

It is also easily possible to keep sources and build trees in various
configurations, see the command line options of ./gen_makefile.py.


=== Install in /usr

By default, the Osmocom install prefix is /usr/local, while (currently) the
default systemd *.service files expect binaries installed in /usr/bin. To
install in /usr instead, use prefix_usr.opts, which sets --prefix=/usr.


=== Systemd Service Files

If you encounter problems installing *.service files, no_systemd.opts may help:

Systemd recommends installing service files in the distribution's single
service file location; that may sound sane, but if that location is
/lib/systemd/system, that means even a --prefix=/home/private/prefix ends up
trying to install service files system-wide in /lib/systemd/system, making all
attempts to install to a user-writable location fail.

no_systemd.opts disables installing *.service files.


=== Build Environment

For dependencies, see the "External dependencies" on:

  https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source

If /usr/local/ is not writable by your user, pass the --sudo-make-install
option to gen_makefile.py above (a custom --prefix is not yet supported).

If your system doesn't have this by default, you will need:

  export LD_LIBRARY_PATH="/usr/local/lib"

and

  export PKG_CONFIG_PATH="/usr/local/lib/pkgconfig"

to your environment. To use the installed binaries after installation, also

  export PATH="$PATH:/usr/local/bin"


=== osmo-uninstall.sh

Remove osmocom built binaries and headers from given prefix,
default is /usr/local.


=== src/*

Find other useful scripts in src/, see src/README.


=== ttcn3/ttcn3.sh

Run a given testsuite with docker, so it behaves exactly the same as when
jenkins runs it [1], but use osmo-dev to build all related Osmocom components
and the testsuite, and mount them inside the docker containers. After building
the docker containers for the first time (which takes rather long), this gives
short test cycles: just modify something, run the script again and the relevant
objects will be built directly, already built objects do not need to be
rebuilt. (This is a big speed improvement over just using docker containers as
you don't need to push your sources to a git server first, have the docker
containers fetch the git sources and build the modified component from scratch
again.)

The docker containers are used, so we don't have to maintain a second set of
configs which works without docker (that was tried before, and found not to be
feasible).

Example usage:

  ./ttcn3/ttcn3.sh mgw
  IMAGE_SUFFIX=latest ./ttcn3/ttcn3.sh mgw

More about the testsuites:
https://osmocom.org/projects/cellular-infrastructure/wiki/Titan_TTCN3_Testsuites

[1] https://jenkins.osmocom.org/jenkins/view/TTCN3/

=== Troubleshooting

When using sanitize.opts, osmo-trx is not built with the address sanitizer
enabled. Linking a sanitizer-enabled libosmocore will not work.