Distros that support compiling from source

In general it is recommend to use the packages coming by your distribution and using the related package manager (e.g.dpkg/apt-get on Debian-based system). The task of your distribution is to package software and to configure it such that there are no conflicts.

Sometimes your distribution does not have the software you want or you have other reasons like e.g.

• you need a newer version
• you want to have a special configuration or want to include patches etc.
• you need more performance and therefore want to optimize the software especially for your hardware (processor, ...)

because you want to compile the software yourself (which can be become quite difficult - especially if you do not know all dependencies).

You have then different options:

• rebuild it from the source, usually from a tarball (= *.tar.gz file) or from an upstream source repository like github
• download/install a corresponding pre-built package (directly or by using an unofficial repository)
• use the existing package source from your distribution, update it by hand and create a new package which you then can install.

If you install software not using the package manager, it is strongly recommended to install the software to other places than the package manager use. The destined prefix is /usr/local/. Installing into a new subdirectory of /opt or somewhere in your home folder are also options.

As far as I know, there is no single program that is meant to use use .in files, but using the suffix .in does hint at the fact that it's not the final file. Instead, the .in file will serve as a kind of template or input to generate the file with the same name but without the .in suffix.

In the case of openwsman, an example you'll often find in packages that you can compile from source, is the configure.in file. This is processed by autoconf/automake and results in a file called configure. This new version is an actual shell script that you can execute on the command line.

In turn, the configure script itself can also process certain .in files. As an example, take the file called openwsman.pc.in. There, you'll see lines like

Version: @VERSION@

The thing between the @ symbols is a variable used by the configure script. In the resulting openwsman.pc.in` the value of this variable will be filled in, for example:

Version: 2.4.5

This @(variablename)@ syntax is also recognized by the CMake build system. So running CMake will also transform the openwsman.pc.in file to openwsman.pc. It does this because of the following line in the CMakeLists.txt file:

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/openwsman.pc.in ${CMAKE_CURRENT_BINARY_DIR}/openwsman.pc)

The etc/owsmangencert.sh.cmake is transformed in the same way, but based on the extension I would assume that only the CMake build system does this and not the configure script. In this case, the relevant line is found in the etc/CMakeLists.txt file:

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/owsmangencert.sh.cmake ${CMAKE_CURRENT_BINARY_DIR}/owsmangencert.sh)

So in conclusion, there's no one single piece of documentation that explains this, but it's often used in build scripts like configure scripts or CMakeLists.txt files from CMake.