3. System Administrator Notes
3.1 Dependencies
In order to compile and run mtCellEdit you must have several packages already present on your system:
- A GNU toolchain (gcc, gmake, gawk, etc).
- Qt version 5.
- txt2tags.
- Inkscape (to build the GUI app icons).
- gperf.
These must also include library headers, which some operating systems provide in separate packages.
mtCellEdit then requires various libraries that I have created:
Package | Dependencies | Description |
libmtKit | zlib, readline | Low level C/C++ routines, including strings, UTF-8, ZIP file handling, preferences, trees. |
libmtPixy | libmtKit, libpng, libjpeg, giflib, FreeType, Pango, Cairo, librsvg | The core pixel engine, including all file handling and general operations. |
libmtCellEdit | libmtKit, libmtPixy, Pango, Cairo | The spreadsheet engine, including all file handling and general operations. |
libmtQEX | libmtKit, libmtPixy, Qt5 | Various Qt function utilities including preferences editor. |
The other optional parts of the suite have these dependencies:
Package | Dependencies | Description |
libmtDataWell | libmtKit, libmtPixy, libsqlite3, libsndfile, libgmp, libmpfr | Crypto, math, and random data library. |
libmtGin | libmtKit, libmtPixy, libsndfile, SDL2, libgl | Graphical Interface Nexus library (SDL, OpenGL). |
mtCedUtils | libmtKit, libmtPixy, libmtCellEdit | Command line spreadsheet tools, including: mtNetLog, mtRDC, mtCedCLI. |
mtCrul | libmtKit, libmtPixy, libmtGin, libmtDataWell, libmtQEX, Qt5, libgl | Point cloud measuring tool. |
mtDataWell | libmtKit, libmtPixy, libmtDataWell, libmtQEX, Qt5 | Crypto and random data app. |
mtDWUtils | libmtKit, libmtDataWell, libgmp, libmpfr | Command line crypto, math, and random data utilities, including: mtDWCLI, mtNushUtils. |
mtGinUtils | libmtKit, libmtPixy, libmtCellEdit, libmtGin, SDL2, libgl | mtGin utilities (audio, graphics, and threading demos). |
mtPixy | libmtKit, libmtPixy, libmtQEX, Qt5 | Pixel image editor. |
mtPixyUtils | libmtKit, libmtPixy | Command line pixel image tools, including: mtPixyCLI. |
mtRaft | libmtKit, libmtCellEdit, libmtQEX, Qt5 | Directory analysis. |
mtUtils | libmtKit | Command line low level utilities. |
3.2 Compilation
As outlined above you must build and install the packages in this order:
- libmtKit
- libmtPixy
- libmtCellEdit
- libmtQEX
- mtCellEdit
In all cases you use these commands to compile the programs:
./configure make
Don't forget to study the makefile and configure script before doing anything. For the complete set of configure options use:
./configure --help
The build system I have created uses simple hand built scripts and makefiles. I find this the best way to build the various components of the project. More elaborate systems like GNU Autotools are of no interest to me as they do not solve any problems I have (portability outside the GNU/Linux ecosystem is of no interest to me).
3.3 Installation
Once compilation is completed, use this to install (you must have root user rights):
make install
You can change the destination directory at this stage if you are creating a package by using:
make install DESTDIR=/my/chosen/directory/
3.3.1 Program man Pages
All of the programs in the mtCellEdit suite have usage information contained in the associated man page. This can be read in the usual way using the man program, such as this example:
man cedutils
3.4 Uninstalling
You can uninstall the program and libraries by using (you must have root user rights):
make uninstall
You will also need to remove any preferences files which are kept in the user directories such as /home/user/.config/mtcelledit/prefs.txt
3.5 Package Management
I aim to get my software working on as many different GNU/Linux systems as possible. To achieve this rationally without testing on hundreds of systems, I work towards compatibility with these system types: Debian, Fedora, and Arch. In doing so I will also achieve compatibility with similar systems.
To achieve these goals as quickly and as easily as possible I use various scripts in the /pkg/ directory to install and test the software (including how I package the software using native package management tools such as pacman, dpkg and rpm). The README.txt file in /pkg/ documents how I do these things, step by step.
The scripts for the different systems all do very different jobs but their interface at the command line is identical. For example to build and install on different platforms using the native package management system you could use:
./build_arch.sh --preconf "CC=clang" ./build_debian.sh --conf "debug" ./build_fedora.sh --conf "--libdir=/usr/lib64"
If your system doesn't use pacman, dpkg, or rpm then you can always use the classic ./configure, make, make install based script using the same arguments:
./build_install.sh --preconf "CC=clang" --conf "--libdir=/usr/lib64"
And if you want to remove all of the installed packages from your system, just use one of these:
./build_arch.sh remove ./build_debian.sh remove ./build_fedora.sh remove ./build_install.sh remove
Here are the options that are available to these 4 scripts:
flush | Clear out the temporary files after a compilation. |
remove | Remove all installed files from a previous build and install. |
--preconf ARG | Add environment variable settings such as CC or CFLAGS. |
--conf ARG | Pass arguments to the configure script such as --libdir or debug. |
--bcfile ARG | If you want to pass different configure lines to different packages you would use a custom built bcfile. See /pkg/ for a few examples example of this. When using --bcfile the options --preconf and --conf do nothing. |
Normally all of the different packages are built in sequence. However you can also pass specific package names to build and install just those items, such as:
./build_install.sh libmtkit libmtcelledit
To remove these items you would use:
./build_install.sh libmtkit libmtcelledit remove
3.5.1 Local Installation
Sometimes it is desirable not to install the program files on the system, and instead install somewhere else using the --prefix= configure script argument such as:
- ~/test_a/usr
- ~/test_b/usr
- ~/test_c/usr
This could be because a user does not have permission to install on the system, or because you want to have different test versions all using different versions of the core libraries.
In this case you must use the build_local.sh script like this:
DIR="$HOME/test/usr"; ./build_local.sh \ --preconf "LDFLAGS=-Wl,-rpath=$DIR/lib" \ --conf "--disable-man --prefix=$DIR"
For a longer example see the file: ./pkg/README.txt