How Builds Really Work and Even More Options

This section describes how builds really work if you want to know more about making changes or understanding the process; probably only for a developer or system administrator.

Builds occur in 4 basic steps:

  1. unpack/patch source code
  2. configure build
  3. make build targets
  4. installation

So, an example of what happens in 4 steps for a single-user build would be as follows:

  1. unpack/patch source code:
    git clone --depth 1 “git:/.../target” cinelerra5
  2. configure build:
    ./configure –with-single-user
  3. make build targets:
    make 2 > &1 | tee log
  4. installation:
    make install

A lot of things can be tweaked to change the results. Mostly these changes are parameters to the configure step, which can change important build related items, like the application name, or where and what the target system directories should be. This makes it possible to have several versions at the same time on the same computer if needed. To see what it is that the makefiles use to build CINELERRA-GG, look at the resulting top-level global_config file which is created by the ./configure step.

Building CINELERRA-GG requires many thirdparty libraries, and it is recommended that you use the static build version included in the git repo. Some of them are patched, and fix significant bugs. It is important to note that because system installation historically has been with as many shared objects as possible, the defaults are that any system library detected during configuration setup will be used, when the package is built --without-single-user, which is the default build. To build with static thirdparty libraries for system install to the system /usr area, use:

.configure --enable-static-build –prefix=/usr

Sometimes, additional package parameters and variables are needed during thirdparty builds. These optional values occur before and after the configure and make commands during a build. A presentation of the format of the package qualified variable names and how they appear in the build procedure are:

 pkg.cfg_vars prepended to configure
 pkg.cfg_params appended to configure
 pkg.mak_vars prepended to make
 pkg.mak_params appended to make
 pkg.cflags added as CFLAGS+=$(cflags) to pkg.vars
 pkg.cppflags added as CPPFLAGS+=$(cppflags) to pkg.vars

These steps are done for EACH of the packages in the thirdparty build:

<pkg.cfg_vars> ./configure <pkg.cfg_params>

<pkg.mak_vars> make <pkg.mak_params>

The thirdparty Makefile has a set of default vars and params used to build each of the needed thirdparty packages, but you can specify new or overriding values for these Makefile substitutions. These thirdparty build config changes are specified in the top-level file: cin_config. By using this file, you can save the configuration changes made for the current build to use the next time you do a new build. For example, to add an include file path to the giflib build, add this line to cin_config:

giflib.cflags := -I/usr/local/include/giflib5

To have a param/var change apply to all thirdparty builds, use:


CFLAGS, CXXFLAGS and LDFLAGS are forwarded to the thirdparty build environment via:

CFLAGS=-ggdb ./configure --with-single-user

However, there is no guarantee that the thirdparty build will honor the environmental flags.

Finally, there are build controls, which enable/disable and set build features.

A few of the more useful ./configure --parameters are:

–with-jobs=n where n=number of build jobs; defaults to 1.5*cpus+2
–enable-static-build build all 3rd party libs; defaults to yes if single-user, else no
–with-single-user build installs to <build_path>/bin; no system installation

The ./configure command builds global_config. The global_config is read by the thirdparty/Makefile to create the recipes and definitions used by the thirdparty build.

There are a lot of different options. Thirdparty library build control is available in the configure step of the build. Thirdparty libraries are built on a demand basis. So if you use:

–enable-libname=auto the static-build enable, or the lack of a system library causes a build  
–enable-libname=yes this forces the thirdparty build  
–enable-libname=no this forces no thirdparty build  

FFmpeg is a strongly connected component in the build linkage and widely influences the CINELERRA-GG library demands. It is possible to make small additions to the ffmpeg configuration step using the environment variable FFMPEG_EXTRA_CFG. For example, to eliminate the use of libvdpau (an nvidia support library) in the ffmpeg configuration step after you have determined that it is causing an error, use:

The CINELERRA-GG Community, 2021