The Python interpreter is preinstalled in most Linux distributions. According to the TIOBE ranking, python is currently the most cited programming language in search queries. It has a low entry threshold, but it has a wide range of uses.

Using python and Linux “in tandem” can make your life a lot easier. I will talk about how to configure python in Linux to suit the needs of your project.

Defining a Virtual Environment

A virtual environment (or virtual environment) is an isolated environment for a project. It is a “sandbox” where an application runs with its own versions of libraries whose updates and changes will not affect other applications using the same libraries. Thus, the use of virtual environments avoids version conflicts.

The virtual environment with all the necessary settings can be “transferred” along with the application. This makes it easier for another developer to work with your project.

Also, libraries which are needed only in one project can be loaded into the virtual environment and thus do not clog up the global environment.
Checking the python version

As mentioned earlier, python is preinstalled in most Linux distributions. I used Ubuntu version 20.04. You can check the current version of python by using the command: python3 -V.

Updating packages

First I will describe how to work with python libraries on Linux.

The Advanced Package Tool (apt) is a package manager which allows to do different manipulations with packages: install, remove, upgrade, search, download without installing them. All dependencies will be resolved automatically.

A package is an archive containing binary and configuration files, information about where to put them in the file system and a list of installation steps. In Linux python libraries are packages.

Linux has a list of repositories from which packages are installed. The list is stored in the text file /etc/apt/sources.list, and in the directory /etc/apt/sources.list.d/. When you run apt update, apt accesses the list of repositories and from each repository in the list retrieves information about the packages in it. All this information is stored in the operating system.

If a new version of a library is released, apt won’t know about it until the information in the repositories is updated. Therefore if you install a package without updating it, the version of the package that is currently installed will be installed.

To update packages, the following two commands must be run.

The first command: sudo apt update.

The second command: sudo apt -y upgrade.

The -y flag in the command denotes automatic confirmation of installation requests.
Installing the venv package

To work with the virtual environment in Linux you need to install the venv package with the command sudo apt install python3-venv.

Creating a virtual environment in Linux

You can create a virtual environment with the command python3 -m venv my_venv.

My_venv is the name of the virtual environment.

The above command creates a directory named “my_venv” (as well as parent directories that don’t already exist) containing the pip package manager, interpreter, scripts and libraries.

You can use the ls -la command to see the files in the current directory.

If you want to create an environment folder in a specific directory, you must specify the path to the folder instead of the environment name. For example, python3 -m venv ~/my_venv.

The pyvenv.cfg file contains a key that will point to the version of Python for which this command is run.

The bin directory contains a copy/symbolic reference of the Python binaries.

The include directory includes the C headers that compile the Python packages.

The share directory includes python wheels. Python wheels is a ready-made package format for Python that helps speed up software development by reducing the number of compilation operations.

The lib directory in the virtual environment has the same structure as the lib directory in the global environment. And it contains a site-packages folder where the libraries are installed.
Activating the virtual environment.

The virtual environment is created. You have to activate it to start using it.

To start using this virtual environment you have to activate it by running the script called activate:

After activation the console line will be prefixed with the name of the environment.

You can check the version of python.

It is also possible to see a list of installed libraries in the environment.

Installing libraries inside the virtual environment

I will try to install the library inside the environment.

After activation, all libraries will be installed in this virtual environment.

To check how the library is installed, you can try importing it.

If there were no errors when importing, it means that the installation of the library was successful.
Sharing a virtual environment

If you want others to be able to run your project code on their computers, they must have the same versions of the libraries as you do.

To do this, I will create a file with all the libraries and their versions.

Run the following command:

The requirements.txt file contains all the libraries (with their versions) that are installed in this environment.

You can install all these libraries by running a single command in the terminal: pip install -r requirements.txt.

After successful installation of libraries, another person can run your project on his computer.
Deactivating virtual environment

The command deactivate can be used to leave a virtual environment.

In this post I have discussed the topic of virtual environments in Linux. This material will allow you to be more aware of the development process and will make it easier to support your projects.

The post Setting up a Virtual Environment in Linux appeared first on B&S_1.

Quick instructions

If you are already familiar with the sequence of steps:

tar -jxvf gwyddion-2.49.tar.xz
cd gwyddion-2.49
./configure
make
make install

Unpack the source code

Unpack the archive with the source code with the command

tar -Jxvf gwyddion-2.49.tar.xz

replacing 2.49 with the current version number. This will create the directory gwyddion-2.49 (again with the current version number instead of 2.49), use cd to navigate to this directory. All other build activities will take place there.

If your operating system does not have xz, you can load gwyddion-2.49.tar.gz (compressed with gzip) instead of the previous archive and unpack it with

tar -zxvf gwyddion-2.49.tar.gz

However, modern Unix and similar systems support both gzip and xz, and the noticeably smaller gwyddion-2.49.tar.xz will usually be a better option.

Configuring

Run

./configure

to configure the build of Gwyddion.

The shell script configure tries to guess the correct values for the different variables that change from system to system and that are used during the compilation. It uses these variables to create a Makefile in each package directory, a set of header files with an .h extension that contain system-dependent definitions and some other auxiliary files. At the end it creates another shell script config.status, which can then be used to repeat the current configuration, and a file config.log, which contains details about the detection process and is useful to include in compilation error messages. At the end, configure also outputs a summary of the optional options enabled and disabled, including the reasons why the option was disabled.

If configure writes that the required packages are missing, install those packages and restart it. The same is true if configure succeeds but you find that you forgot to install the optional component you wanted to build Gwyddion with. It is possible that the package was not found or was incorrectly defined even if you installed it, namely if it was installed in a non-standard directory. In this case you should set up certain environment variables to allow you to find these packages:

PKG_CONFIG_PATH

Most packages come with so-called pkg-config (.pc) files which describe how programs are to be built and linked to them. Configure uses the information from these files, therefore the PKG_CONFIG_PATH must be set up so that all the non-standard pkg-config files are listed there. To add e.g. the installed GTK+ library to /opt/gnome and the installed FFTW3 library to $HOME/opt/fftw3, run PKG_CONFIG_PATH=/opt/gnome/lib/pkgconfig:$HOME/opt/fftw3/lib/pkgconfig export PKG_CONFIG_PATH

PATH, LD_LIBRARY_PATH, DYLD_LIBRARY_PATH

You might have to adjust these variables to include non-standard directories with executables and libraries of corresponding packages. The variables LD_LIBRARY_PATH and DYLD_LIBRARY_PATH both specify a search path for shared libraries, but the former is used on Linux and BSD-based systems, whereas the latter on OS X.

CPPFLAGS, LDFLAGS

It may be necessary to set these variables to include non-standard directories with header files and package libraries that have no pkg-config files, e.g. for libTIFF in /usr/local you can set CPPFLAGS=I/usr/local/include export CPPFLAGS LDFLAGS=L/usr/local/lib export LDFLAGS

The –prefix option of configure specifies the base directory for the installation. The program components will be installed in its subdirectories bin, lib, share, etc. (which will be created if they do not exist). More detailed control is possible with options specifying individual subdirectories, such as –bindir, –libdir. The default prefix is /usr/local/bin and if you want to install Gwyddion in the user’s home directory you can use e.g. the command

./configure –prefix=$HOME/opt/gwyddion

If you are installing Gwyddion for personal use this is the recommended option, as it does not require superuser privileges.

Configuration process settings

Optional features can be enabled/disabled with options like –with-foo/–without-foo or –enable-foo/–disable-foo. For example, compiling with zlib can be disabled with the command:

./configure –without-zlib

By default, all optional features are enabled if all libraries required to implement them are found. A summary of the enabled and disabled options is printed in the output of configure near its end.

A complete list of options and important configure variables can be obtained with the command:

./configure –help

The list will be long and most of the options control the enabling/disabling of individual options or passing the necessary compilation and linking flags for the various libraries. For example, by setting FFTW3_CFLAGS and FFTW3_LIBS it is possible to specify (or override) how FFTW3 will be compiled and linked. However, this manual configuration is just a fallback to a much more convenient method based on pkg-config in case this does not work for some reason.

Some interesting general options are described in the following paragraphs.

User settings

Gwyddion comes with various desktop environment interaction files that define MIME types, menu items, file bindings, thumbnail generation, etc. If Gwyddion is installed in the system directory, they are usually in the correct locations on the file system. However, if you install it somewhere in your user directory, these files need to be put in a different location. namely, in certain hidden directories beginning with a dot in your home directory.

This can be set using the –enable-home-installation option of the configure command. Note that using this option will cause files to be installed in directories outside the given prefix.

Package creator settings

If Gwyddion is installed in a temporary directory for further package creation, certain post-installation steps must be disabled on the system where the package will be installed and not at the time of package creation.

FreeDesktop file updating can be disabled using –disable-desktop-file-update. The installation of GConf2 schemas can be disabled with –disable-schemas-install. Normally this need not be done explicitly because installs to a temporary directory use the non-empty DESTDIR variable (see installation section). If the DESTDIR variable is not empty, the build system will skip the post-installation steps automatically. However, a common reason to disable these actions is that Gwyddion is installed in a temporary location instead of the final directory (which is usually the case when building packages in Linux). In this case the helper actions are turned off automatically when the DESTDIR variable is not empty (see the installation section) and therefore there is no need to turn them off in configure.

By passing the –enable-library-bloat parameter to the configure script, it forces modules to link to all libraries. This is automatically enabled on MS Windows, where it is a requirement. On Unix-based systems, linking modules with all the libraries already loaded by the main program only slows things down in vain (both at build time and run time). Thus, modules are not linked directly to main libraries like GLib. If your system or build rules require linking modules to all libraries (on AltLinux based systems for example), using this option enables this behavior.

By passing the –disable-module-bundling option to configure, you can prevent all modules of the same type (file, data processing, …) from being bundled into the same shared library, which is usually done to save disk space and speed up booting. Although this does not change the functionality, it does noticeably change the set of files to be installed. If you are relying on gwyfile.so for whatever reason, it is time to stop doing this. However, you can use this option to force a traditional install where each module is in a separate file.

Settings for developers

If you plan to patch or otherwise modify the source code of Gwyddion run configure with –enable-maintainer-mode to include various update and rebuild rules that are not used in normal compilation. Depending on the type of changes, you may need some additional tools, described in Subversion Snapshot, development.

By default, the C API reference guide is not rebuilt. Prepared HTML files are distributed with the archive, documentation is rarely changed and its generation requires quite a long time. In order to enable API documentation generation, the –enable-gtk-doc option must be passed to the configure script. Of course, you will need gtk-doc. Note that configure will warn you if you have enabled maintainer mode but not gtk-doc (which can be useful to avoid having to rebuild documentation pointlessly and overly). If you do not intend to do make dist, this warning is harmless.

Compiling

Run

make

and wait for Gwyddion to compile. If the configure command completes without errors, the compilation should also succeed. To reduce your waiting time, you can enable a parallel compilation by running make with

make -j6

where 6 should be replaced by the real number of processor cores available.

If you need to do something unusual to build a package, try to figure out how to find out when and what to do, and send patches or instructions to the bug reporting email address so you can include them in the next release.
Installing

Gwyddion must be installed before running, it cannot be run uninstalled.

Run

make install

to install Gwyddion into the target directory. If you install Gwyddion in the system directory, you will need to become root in order to run this command. This is the only command you have to run as root when installing. For example, using sudo

sudo make install

To install Gwyddion to a temporary location, for example to build a package, set the make variable DESTDIR to a prefix that will be added to all target directories:

make install DESTDIR=/var/tmp/gwyddion-buildroot

Do not override individual directory variables such as bindir, libdir.

If you are not installing into the system directory, i.e. installing into a subdirectory of your home directory, you may need to configure the following environment variables during the installation

GCONF_SCHEMA_CONFIG_SOURCE – the location of the GConf2 schemas KDE4_MODULE_DIR – location of KDE4 modules

You may also need to set the XDG_DATA_DIRS variable for full integration with the desktop environment.

If you install Gwyddion to /usr/local and get the error message libgwyapp.so.0 cannot be found, your system seems to be missing standard directories for libraries in the dynamic linker setup. This has been seen on Ubuntu. Edit your /etc/ld.so.conf file and add the line

/usr/local/lib

Running

Running Gwyddion normally requires no additional configuration.

But some desktop environments that are implemented incorrectly can render Gwyddion unusable and this functionality should be disabled. Hijacking the program’s main menu in Unity makes most of the Gwyddion menus inaccessible. This can be turned off by resetting the environment variable UBUNTU_MENUPROXY when you start Gwyddion:

UBUNTU_MENUPROXY= gwyddion

Cancel installation

Run

make uninstall

in the directory where Gwyddion was previously built to remove it. If you have already lost the contents of this directory, you can try to unpack, configure and build it exactly the same way as before and then run make uninstall afterwards, though the result depends on your ability to exactly repeat the build process.

RPM packages

With GNU/Linux RPM-based distributions, it is possible to build RPM packages directly from the source archives by invoking

rpmbuild -tb gwyddion-2.49.tar.xz

where 2.49 is the current version, as mentioned before. This method has been tested with Fedora, openSuSE and Mandriva and the RPM spec file contains some specific directives for those systems. Specific support for other RPM-based systems can be added on request.

The post Build in a Linux/Unix environment appeared first on B&S_1.

Vulkan Packages

The most important Linux components for Vulkan development are the Vulkan loader, validation layers and a few command line utilities to check your computer’s compatibility with Vulkan:

• sudo apt install vulkan-tools: command line utilities, most notably vulkaninfo and vkcube. Run them to see if your PC supports Vulkan.
• sudo apt install libvulkan-dev: installs the Vulkan loader. The loader looks for driver methods in rantime (at runtime) in the same way that the GLEW library does for OpenGL.
• sudo apt install vulkan-validationlayers-dev: installs the standard validation layers that are needed when debugging programs with Vulkan. We’ll talk about them in the next chapter.

Also don’t forget to run vkcube, after which the following should appear on your screen:

GLFW

As already mentioned, Vulkan is a platform-independent API with no tools to create a window to display rendering results. To take advantage of Vulkan’s cross-platform nature and avoid the horrors of X11, we will use the GLFW library for window creation. There are other libraries available, such as SDL, but GLFW is better in that it abstracts not only window creation, but also some other platform-dependent functions.

We will install GLFW using the following command:

sudo apt install libglfw3-dev

GLM

Unlike DirectX 12, Vulkan doesn’t have a library for linear algebra operations, so you’ll have to download it separately. GLM is a nice library designed to be used with graphics APIs and is often used with OpenGL.

The GLM library is a header only library. It can be installed from the libglm-dev package:

sudo apt install libglm-dev

Shader compiler

Now that the setup is almost complete, it remains to install a program to compile shaders from GLSL to bytecode.

The two best known shader compilers are glslangValidator from Khronos Group and glslc from Google. In terms of usage glslc is similar to GCC and Clang, so we will opt for it. Download the binary and copy glslc to /usr/local/bin. Note that, depending on your permissions, you may need to use the sudo command. Run glslc to test, and you should get a warning:

glslc: error: no input files

We will look at glslc in detail in the chapter on shader modules.

Setting up a project for a makefile

After installing all the libraries we can set up the makefile project for Vulkan and write some code to make sure everything works.

Create a new folder in a convenient location and name it VulkanTest. Create a file named main.cpp and paste the code below into it. You don’t have to try to understand it now, it’s important to know if the program will build and run. In the next chapter, we will start with the basics.

#define GLFW_INCLUDE_VULKAN

#include . <GLFW/glfw3.h>

#define GLM_FORCE_RADIANS

#define GLM_FORCE_DEPTH_ZERO_TO_ONE

#include <glm/vec4.hpp>

#include <glm/mat4x4.hpp>

#include <lostream>

int main() {
glfwInit();

glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API);

GLFWwindow* window = glfwCreateWindow(800, 600, “Vulkan window”, nullptr, nullptr);

uint32_t extensionCount = 0;

vkEnumerateInstanceExtensionProperties(nullptr, &extensionCount, nullptr);

std::cout << extensionCount << ” extensions supported\n”;

glm::matrix; glm::vec4 vec; auto test = matrix * vec;

while(!glfwWindowShouldClose(window)) {

glfwPollEvents();

}

glfwDestroyWindow(window);

{ glfwTerminate();

return 0;

}

The next step is to write a makefile to compile and run. Create a new empty file named Makefile. It is assumed that you already have initial experience with makefiles. If not, this tutorial will get you up to speed quickly.

First, you need to define a few variables to simplify the rest of the file. Define a variable, CFLAGS, to hold the base flags of the compiler:

CFLAGS = -std=c++17 -O2

We use modern C++ (-std=c++17). We also set the O2 optimization level. You can remove the -O2 level for faster compilation of programs, but you still need to return it for the release build.

Similarly, define the linker base flags in the LDFLAGS variable:

LDFLAGS = -lglfw -lvulkan -ldl -lpthread -lX11 -lXxf86vm -lXrandr -lXi

The -lglfw flag connects the GLFW library, -lvulkan connects the Vulkan loader, and the other flags are low-level libraries and dependencies of GLFW itself.

Now you should have no problem defining a rule to compile VulkanTest. Don’t forget to use tabs instead of spaces for indents.

VulkanTest: main.cpp
g++ $(CFLAGS) -o VulkanTest main.cpp $(LDFLAGS)

Check that the build works. Save the makefile and run make from the folder with main.cpp and Makefile. This should result in an executable VulkanTest.

Now you need to set up two more rules, test and clean. Test launches the executable and clean deletes it.

PHONY: test clean

test: VulkanTest
./VulkanTest

clean:
rm -f VulkanTest

Running the make test command will make sure that the program runs successfully. When you close the empty window, the program should end with a successful return code (0). You should end up with a makefile similar to the one below:

CFLAGS = -std=c++17 -O2
LDFLAGS = -lglfw -lvulkan -ldl -lpthread -lX11 -lXxf86vm -lXrandr -lXi

VulkanTest: main.cpp
g++ $(CFLAGS) -o VulkanTest main.cpp $(LDFLAGS)

.PHONY: test clean

test: VulkanTest
./VulkanTest

clean:
rm -f VulkanTest

You can use this directory structure as a template for Vulkan projects. To do that, copy it, rename it, for example, to HelloTriangle and remove all code from main.cpp.

So, now you’re ready for the real adventure.

The post Vulkan – Setting up the Environment appeared first on B&S_1.