Natively compiled software is software written in a programming language that compiles to machine code, with a resulting binary executable file. Such software can be run stand-alone.

RPM packages built this way are architecture -specific. This means that if you compile such software on a computer that uses a 64-bit (x86_64) AMD or Intel processor, it will not execute on a 32-bit (x86) AMD or Intel processor. The resulting package will have architecture specified in its name.

Some programming languages, such as bash or Python, do not compile to machine code. Instead, their programs' source code is executed step by step, without prior transformations, by a Language Interpreter or a Language Virtual Machine.

Software written entirely in interpreted programming languages is not architecture -specific. Hence, the resulting RPM Package will have string noarch in its name.

Interpreted languages are either byte-compiled or raw-interpreted. These two types differ in program build process and in packaging procedure.

In this example, you will build the cello.c program written in the C language into an executable.

cello.c

#include <stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}

gcc -g -o cello cello.c

$ ./cello
Hello World

cello:
        gcc -g -o cello cello.c

clean:
        rm cello

$ make
make: 'cello' is up to date.

$ make clean
rm cello

$ make
gcc -g -o cello cello.c

$ make
make: 'cello' is up to date.

$ ./cello
Hello World

The next two examples showcase byte-compiling a program written in Python and raw-interpreting a program written in bash.

#!/usr/bin/env python

print("Hello World")

$ python -m compileall pello.py

$ file pello.pyc
pello.pyc: python 2.7 byte-compiled

$ python pello.pyc
Hello World

#!/bin/bash

printf "Hello World\n"

$ chmod +x bello
$ ./bello
Hello World

Sometimes using build automation tooling such as GNU make is not optimal - for example, if the packaged program is simple and does not need extra overhead. In these cases, packagers often use the install command (provided to the system by coreutils), which places the artifact to the specified directory in the filesystem with a specified set of permissions.

The example below is going to use the bello file that we had previously created as the arbitrary artifact subject to our installation method. Note that you will either need sudo permissions or run this command as root excluding the sudo portion of the command.

In this example, install places the bello file into /usr/bin with permissions common for executable scripts:

$ sudo install -m 0755 bello /usr/bin/bello

Now bello is in a directory that is listed in the $PATH variable. Therefore, you can execute bello from any directory without specifying its full path:

$ cd ~

$ bello
Hello World

A popular automated way to install built software to the system is to use the make install command. It requires you to specify how to install the arbitrary artifacts to the system in the Makefile.

Add the install section to the Makefile:

Makefile

cello:
        gcc -g -o cello cello.c

clean:
        rm cello

install:
        mkdir -p $(DESTDIR)/usr/bin
        install -m 0755 cello $(DESTDIR)/usr/bin/cello

The $(DESTDIR) variable is a GNU make built-in and is commonly used to specify installation to a directory different than the root directory.

Now you can use Makefile not only to build software, but also to install it to the target system.

To build and install the cello.c program:

$ make
gcc -g -o cello cello.c

$ sudo make install
install -m 0755 cello /usr/bin/cello

Now cello is in a directory that is listed in the $PATH variable. Therefore, you can execute cello from any directory without specifying its full path:

$ cd ~

$ cello
Hello World

You have installed a build artifact into a chosen location on the system.

The bello project implements Hello World in bash. The implementation only contains the bello shell script, so the resulting tar.gz archive will have only one file apart from the LICENSE file. Let us assume that this is version 0.1 of the program.

Prepare the bello project for distribution:

The pello project implements Hello World in Python. The implementation only contains the pello.py program, so the resulting tar.gz archive will have only one file apart from the LICENSE file. Let us assume that this is version 0.1.1 of the program.

Prepare the pello project for distribution:

The cello project implements Hello World in C . The implementation only contains the cello.c and Makefile files, so the resulting tar.gz archive will have only two files apart from the LICENSE file. Let us assume that this is version 1.0 of the program.

Note that the patch file is not distributed in the archive with the program. The RPM Packager applies the patch when the RPM is built. The patch will be placed in the ~/rpmbuild/SOURCES/ directory alongside the .tar.gz.

Prepare the cello project for distribution:

Now the source code is ready for packaging into an RPM.