hpr-knowledge-base/hpr_transcripts/hpr1688.txt

Episode: 1688
Title: HPR1688: Some useful tools when compiling software
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1688/hpr1688.mp3
Transcribed: 2025-10-18 07:44:37

---

This is HPR Episode 1688 entitled Some Useful Tools When Compiling Software.
It is hosted by first-time host row and end is about 13 minutes long.
The summary is useful tools I found when compiling software and creating a Debian package.
This episode of HPR is brought to you by AnanasToast.com.
Get 15% discount on all shared hosting with the offer code HPR15. That's HPR15.
Better web hosting that's honest and fair at AnanasToast.com.
Hi, this is Rowan and welcome to my first submission to HPR Public Radio.
I've been working on an application using the Python programming language
with the Enlightenment Foundation Libraries, EFL Libraries, for the GUI interface.
After acquiring a new laptop and installing a fresh copy of Ubuntu on it,
I decided to set up the build environment I needed to be able to work on my project.
I've been building from source the EFL Libraries along with the Python EFL wrapper libraries.
For the last couple of machines on which I built the software,
I would use a standard configure, make, and make install procedure.
This time around I decided to create a Debian package to use for installing the libraries.
But a few years since I had created a Deb, so I googled to look for some tutorials and found
mention of the check install program. After reading a couple blog posts about it, I decided to try it out.
Check install is run instead of make install and will create a Deb file and then install the newly created package.
To help speed up the configure process, I had previously created a file from my other builds
that is a grip of my history for all the various AppGet install commands of the libraries,
the EFL software needs to compile. Since my current operating system was a
freshly installed Debian distribution, I needed to install the build essential package first.
After looking through my install file and I decided to create a single
AppGet install line with all the packages listed instead of like going through each one
and AppGet install this library, AppGet install that library, I would just have one command
that would install them all at the same time.
Let's see, I knew I could grip this file I had for my history and then pass it to Auger said,
but my skill with either of those isn't that great.
I did a little searching to see what other tools were out there and found the cut command and
the TR command. Cut lets you print part of a line. You can extract a field from the line using
by setting the field delimiter with a dash D option and then list a range of fields to be
printed with the dash F option. So basically it's cut dash D and I used a space as my delimiter
and then I think it was dash F 7 for the 7th field or 7th or 8th field is what it worked out
to be for I think sudo AppGet install name of your library. So this then gives you a one
per line of the list of the packages you need and then by piping that to the TR command which
can replace a character, I was able to replace the new line character with a space so that
when I piped my grip of the install lines passed that to cut, passed that to TR, I then ended up with
a nice line of space separated packages which I outputted to a file. Then it was just a matter of
editing the file to add sudo AppGet install to the beginning of the line, there was a little clean
up to do and then save that, change the permissions on the file and then I had a nice easy to install
command to get all the packages I needed in one fell swoop. So that worked out pretty nicely.
At least that was the idea. After installing the libraries and running configure, I still
received errors that the libraries were missing. The machines from which my list of libraries
were generated had all been used for various development purposes. So apparently some of the libraries
that were needed were already installed on them and by the time I was doing my grip of history,
they had already passed out of the history. So I did have to figure out some more libraries that were
needed. When you're running configure, it will echo out everything it's doing and then when
it can't find a library, it will push this out to the standard out and it also creates a
config.log so that if you can't quite figure it out, you can get some more hints from what's
in the config.log. It's really not that hard usually to figure it out. Often the libraries needed
include their name in the .dev which has to be installed and find in them is easy
with just an app cache search and grip of the library name. I often had to pipe that to another
grip with looking for devs. Often you want to install the development version of the libraries to
make sure you get all the headers you need. So this works pretty good and I had done it a number of
times. There's a number of dependencies when you're building the FL libraries. But I do run into
issues trying to find x11-based references. In this case, I needed the screensaver.h header file.
After googling, I found a reference to the needed package with the excess .dev on stack exchange.
The answer also showed how to use the app file command to determine which package a file is
concluded. So I wish I'd run into this before. There are a few times where it took a number of
searches on the internet to figure out which package I needed to install. Sometimes you can find
a reference to a similar package and say like an rpm or something and then you sort of have to
figure out what its mate is in like a devian distribution. But at this post, I found they were
saying, I'll just use the app-file command and it's the app-file find, the name of the file.
And that will give you the name of the devian package that the file was founded.
I wish I'd found this a lot earlier. It would have saved a lot of time and frustration on some of
my previous builds of these libraries. But as it is, it's a great tool now to have in my toolbox.
I'm very happy to find it and look forward to using it in the future.
So, this brings me to finally running config again and it turned out that that was the last
dependency I needed. So while I didn't actually need that file, because of course I found it in my
the package I was looking for in my search, like I said, it will be a good tool to have handy for
any future builds where I run into issues. So now I was able to successfully run
configure, then successfully compile using the make command, and I was ready to try out check install.
So I just run pseudo check install that brings up a series of questions about your package,
helping you fill out the needed metadata. I filled out my name and email, the name of the package,
a short description of the package, and then I let everything else go to the suggested defaults.
After that, you just enter, and check install will create a devian package and install it for you.
If you run appcache search, I call mine EFL, and I think EFL Python for the Python libraries,
they show up in the list. And if you do like appcache show EFL, it would show the name of the package,
a mine description, and my name and email, and all that fun stuff about the package. So,
works checking install, at least for me, work great. There are warnings on the Ubuntu Wiki
not to use this method for packages to be included in an archive or in a PPA. Like I said,
it does work great for local install, and I would use it to install on machines on my local network.
So after a short trip into the development setup, I'm back writing my application on my new laptop.
My new and good new laptop. While I'm a big fan of binary packages, devian being the first
new Linux distribution I ever use, sometimes you do need to dive in and compile software from source.
For me, running configure, make install has been the easiest way to do this, and these days
it usually isn't too difficult to get even moderately complex applications in libraries to build.
The most tedious part can be resolving all the dependencies, and now with app-file,
in my tool belt, it will be even faster and easier. I will be using check install for future
compiles. I do like being able to use package management tools to install and uninstall software.
I hope others find these tools useful. I've posted the links in the show notes to the pages about
cut, TR, app-dash-file, and check install that led me to these tools. If you've made it this far,
thanks for listening to my first episode of HPR. As Ken Fallon points out, it's not an HPR
episode until you've uploaded it to the server. So let's keep those episode ideas flowing from
our brains into our favorite recording devices and up to the server. Let's keep HPR active,
vibrant, and a part of our lives for years to come.
You've been listening to HECKAPOBLICradio.org. We are a community podcast network that
releases shows every weekday Monday through Friday. Today's show, like all our shows, was
contributed by an HPR listener like yourself. If you ever thought of recording a podcast,
then click on our contributing to find out how easy it really is. HECKAPOBLICradio was founded
by the digital dog pound and the infonomicum computer club, and it's part of the binary
revolution at binrev.com. If you have comments on today's show, please email the host directly,
leave a comment on the website, or record a follow-up episode yourself. Unless otherwise status,
today's show is released under Creative Commons, Attribution, ShareLife, 3.0 license.