Next: Experimental Builds Up: Developer's Section Previous: Developer's Section Contents Index
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:
So, an example of what happens in 4 steps for a single-user build would be as follows:
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:
CFG_VARS, CFG_PARAMS, MAK_VARS, MAK_PARAMS
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