Building a Modern Pascal Pipeline: Lazbuild, Valgrind and Lint Checks

[00:00:00]Hey, everyone, and welcome back. And the words and the tools, they may change, but the actual work and the actions don't. If you listen to people in the tech industry today, you'd swear that something like a CI/CD pipeline had been handed down by the gods on stone tablets to be demanded at all costs. So, and if you're a bit older, like myself, you it's understandable if you do get confused by terms like these or DevOps automation, that it makes it sound like you need to have a whole crew just to compile your software. But, if you were to strip away the marketing side of things, the core reality or ideas haven't changed. And many years ago, we would have had a machine in the corner which was responsible for doing a nightly build, a little bit of anxiety waiting for that build to complete.

[00:00:53]Um But, it would typically take all the source code down, uh compile the software, create the install media, and then go through a testing process. Today, the tools will be more a little bit shinier, but the fundamental goal and that little bit of anxiety waiting for a build to pass, it's going to be the same. And the automation side of things, it doesn't have to be overly complicated or over-engineered in order to be effective. And today, what we're going to look at is, you know, some things that you can do, tools that you'd have on your own machine or can easily install, like Laz Build or Valgrind, to you know, help you to catch these bugs, you know, before they reach or get to your repository. So, why don't we get started? So, before we do anything, we need to go into Lazarus and make sure our compiler is configured to, you know, tell us what we need to know to be able to make sure we haven't done anything silly. So, to do that, we need to go into our project options and under the compiler options and verbosity uh make sure that we have um warnings enabled, notes enabled, as well as hints.

[00:02:11]Uh we also, just as an aside here, we've got some build modes here and we'll talk about them a little bit later on. Like I said, if we have these uh settings enabled, then the compiler will be able to tell us what's happening, what whether a variable is used or not, you know, etc. Um we need to know that sort of information so that we can then take action.

[00:02:33]Now, the uh next thing to be aware of is that um we are going to be using Valgrind as well.

[00:02:42]Uh if you don't have that installed, uh you can do your pseudo, you know, um apt install.

[00:02:50]Uh if you're in Windows, you could probably use something like um Dr. Memory, but today we're on Linux, so that's what we're going to use. So, we just go to our command line here just to make sure we've got everything here and yes, it's all good to go.

[00:03:08]Okay, so the first step, regardless of whether you're you know, jumping onto another machine or using a Git hook, um setting up a build runner, it's unlikely that you are going to you know, go to the other machine, load up an IDE just to compile that program.

[00:03:24]So, the tool here that we can use is called Laz Build and it's one of the tools that you get as part of Lazarus with Free Pascal.

[00:03:33]Now, what it does is to it will allow you to compile a program, but you do not have to worry about the GUI. So, we can do Laz build and just specify the name of the project.

[00:03:49]And you get a whole bunch of information being output. Some of it you might not want to you might consider irrelevant.

[00:03:56]Some of it will be helpful to us. Out of the box that's what we're going to see something like that. Now, if you want to get rid of, you know, some of the junk for lack of a better words, we can run it with a quiet setting and this time here the information which used on the top half is no longer there and you really just see it from when the compiler itself kicks in. There is also a help setting here. So, let's get rid of all of that and if you are unsure of how to use it and this last option here is the one that I'm going to say is of interest to us right now because we can actually ask it to tell us what the build modes are for a particular pro project and we can see here that we have three modes available at the default, a debug and a release. Right, so it can read our project file and our modes and it can tell us what we we can build with it. If we want to, let's say, build a version for a production, you know, we would do something like and if we want to do a debug version here the catch here is that when we now the trick here is that that with all this information that gets output, we may not see the hints and the warnings that get output by the compiler.

[00:05:32]Even with the quiet setting, there is still a lot of information that is output here.

[00:05:38]So, what we can do now is to do something like we can type the output from the compiler or the compiler cuz remember that last build sits on top of, you know, the free pass compiler and linker is to do a grep minus e, look for a space, and then warning or hint or note, and let's see what gets output now.

[00:06:10]Okay, so we've got a config file.

[00:06:14]Now, you can see these last messages here are the ones that we would be interested in. So, if we want our pipeline to be able to flag issues, you know, we can pipe that output to a file, for instance, and it filters out all the other noise. Now, the one thing I should mention is that while Lazarus, you can have projects groups, there is a package for that which you can, install into your IDE.

[00:06:41]Uh you cannot use a project group with Laz build. So, what that means is then that if you've got, let's say, multiple programs that need to be built as part of the build process, then uh you would have to write some sort of script or make file to, you know, go through them individually. Now, compiling is just, you know, half the fun.

[00:07:06]Uh just because it can compile doesn't necessarily mean it can run well. There may be um issues that are not immediately visible to the eye. While there are tools such as heap trace, um leak detection, etc., Valgrind tool allows us to look for um other issues that we may not find. So, in order for us to be able to utilize um this particular tool, we have to go back into Lazarus, and under our project options, and under debugging, uh yes, we do. Under debugging there is this option here that you can check labeled generate code for Valgrind. So, and if you're going to do it from the command line, it's minus GV. That gets included. If that's turned on, then additional information gets added into the output file that you can then use with Valgrind. So, let's run Valgrind with our program now.

[00:08:08]So, here what we're going to be using is the Memcheck tool to show all kinds of leaks and I'm having the output to go to a text file. So, let's run that. See what happens, shall we?

[00:08:21]So, first of all, this program here, and we'll go back to Lazarus for very quickly. What it did is we've got a variable here which is not being initialized after memory has been allocated for it.

[00:08:35]Still has a free memory, so everything is fine there. Also, in the second case or second instance is that memory is allocated 10 elements, but we're going from 0 to 10, which is actually 11. So, we're going to be jumping off the end and there was no exception raised, so I think the program was fine.

[00:08:55]So, let's have a look at the log file from Valgrind. I'm just going to make a little bit smaller here. Okay.

[00:09:04]So, first of all, this report here says that there were errors. One of the issues here that says that there is a jump or move depends on uninitialized values and this one here is and also said that it was uninitialized value was created by heap allocation and we can see that it was on line 40 here it tells us. So, if we go to our program, here go to line 40, it tells us that our error is on this line here from the unallocation there. And the second one basically is telling us that there is an is zero bytes after block of size uh 26 allocated invalid write. Okay, and that's on line 62.

[00:09:50]If we were to go to line 62, then that will be here and we can see that this area here has an issue to be dealt with. Now, there is another tool that you could use uh called uh I'm going to call it Massif.

[00:10:07]m a s s i f. It's another tool that you can use with Valgrind. It can also produce a log file, but it will show you how much memory that your program uses over time. So, the next thing that we can um talk about then is uh linting and that's when you can check the quality of your code without running it.

[00:10:27]Um and there's a few things that you can do here.

[00:10:30]We saw that the output from the um compiler tells us some things like whether or not a variable is initialized or not. It can also tell us whether a unit is used or not. Inside the IDE, we also have some of these things are available there also.

[00:10:46]So, if we go into here and go into into the refactoring, one of the things that we can look for or some of the things we can look for here, empty methods, um unused units, and so on. So, here when we go into refactoring and unused units, it brings up a dialogue and it shows us which units aren't being used at all.

[00:11:10]And we do then have an option to remove all the units. So, if I do turn click on that, then it just basically strips it back to the actual units which are needed by this one here to compile all project in its instance. Now, if we want to, let's say, add some code quality rules before we do a commit, we can use a tool like Ripgrep RG, which it's fast and it allows us to search our code base for regular expressions.

[00:11:40]There are some tools which are being developed, also I think FP Sona have been floating around on the Free Pascal mailing list of late and it will, you know, check your code for issues, but in the absence of tools, you know, that we might be able to use through the IDE, then Ripgrep, you know, becomes the ideal tool to use. So, let's look at some examples of what's possible here.

[00:12:11]So, this first one here, well, what we're going to look for are you know, classes which do not have an override symbol, you know, added or chucked onto the end. We're going to see the line number and like I said, we'll see what Let's see what the output of this would be. So, basically, it tells us what the file is, what the line number is and shows us the line, the offending line. So, that's the first example. Now, this next one will show us a range of sins. Basically, what it will do is can it will return a list of to-do items, fix me, if a go-to is being used, if there's a width block being used in the program. And so, let's see what this one here will output on our code base here.

[00:12:59]Nothing. Okay, so why don't we go into here and let's do something like with and basically, it will bring back again the lines where the issue the issue that it finds is and then you can then take the appropriate action as needed.

[00:13:19]Similarly, one thing you can also do is to make sure, let's say that if we can go back to our code in here, say is that if you wanted all your classes or record structures or types to begin with the letter T, this one here would be incorrect. So, we can check the things like that with this command here.

[00:13:42]So, essentially what we're telling it is to look for a class definition or record definition.

[00:13:51]It's followed by an equal sign. There may be one or more spaces before and after the equal sign. Then we have a value here, but it doesn't start with a letter T. And again, it shows us the line. Ah, because we're in the project.

[00:14:05]Okay. And now, if you don't tell it what file you're looking at, then that gets that information is provided as well.

[00:14:13]Now, you could easily put all of these commands here into a single script or batch file if you're on Windows or PowerShell script to do all these checks, you know, before you submit your code into your source repository. So, by using a, you know, a few simple tools like Laz Build, Valgrind, regex, you know, searches, you know, with Ripgrep, you can create a little tiny pipeline to help keep your application code safe, stable, and clean. It basically allows you to let your machine, you know, check your homework. So, and you can maybe sleep a little bit easier hopefully knowing that it's, you know, the world isn't going to blow up tomorrow. So, maybe one thing you could try is to add some of these commands or tools into your build, you know, setup or maybe even into your local Git hooks.

[00:15:06]And let me know in your comments, you know, other little tricks you would do for linting or building to to handle your automated builds. I'd I'd love to know. So, until next time.

[00:15:18]Cheers.