make is a utility for end users or for programmers/developers?

For example?

Maybe you started to compile something, but there was an error in your code, or you were missing a library dependency.
The compiler started compiling your code, but it never finished because it was broken for some reason.

Once you make the fix, you need to "clean out" all the old broken stuff that didn't compile correctly.
"make clean" should do this for you. But again, that's part of the makefile the developer wrote. A good makefile
will include this.
 


I suspect it'll be around for a long time yet. It's one of the oldest binutils.



This could be a thread all on it's own. But for the most part there are certain ways an application is "packaged".
The two most common ones are .deb and .rpm This gets a little into the family history of Linux and which distro's
spun off which other distros. There are some others I'm less familiar with, portage and pacman come to mind.

.deb packages are used by Debian spin offs, such as Ubuntu, Mint, Parrot and others.
.rpm packages are used by Fedora spin offs, such as CentOS, Redhat, AlmaLinux and others.
There are some utilities that will let you crossover and use .deb on rpm based systems, and .rpm on deb based systems.
but it's been my experience none of them usually work very well.

SuSE isn't really part of the fedora family, but it uses rpms as well.
Arch uses pacman. I think Gentoo still uses portage, but I haven't used that in a very long time.
Hmmm... do we have any Gentoo users on here?

I don't know the exact percentages, but I would guess the vast majority of binary packages have what is called
dependencies. Usually there are library files like libc.so or glibc.so or literally dozens of others. The binary files
usually have to match the version of the library files they were compiled with. Almost all the distro's have different
versions of library files, kernels, build utilities, and compilers.

OK

Make helps with a lot of this. It'll go out and check what versions of what libraries you have and check to see if they're compatible with the source code.

How?

It will also let you run make config to add paths for library files and installations directories.

Meaning what?
 
Last edited:
For example?
"clean" is a pseudo target - no file / program named "clean" is ever produced, but the rules specified in the makefile for when it is out of date (and it's always out of date because it never gets produced) are specified (by the programmer who sets up the makefile) such that temp files are removed (and any other cleanup that needs to be done also takes place).

Similarly, "install" is a pseudo target that never gets produced, but the makefile specifies build rules that, in "trying to produce install", perform what ever actions are needed to install the program.

So typically one could build and install an application, regardless of its complexity, as long as one has a makefile that's configured to do so, with
make clean
make
make install

There are default rules so that, for instance, if hello_world.c exists, "make hello_world" would figure out how to produce hello_world even in the absence of any makefile. In this case, "make clean" and "make install" would not work (producing error messages, I suppose).

The makefile should go into the version control system along with the program source code.
 
Absolute mode: this method represents permissions as 3-digit octal numbers ranging from 0-7.
in symbolic you have 3 basic user representations
u = user/group
g = group
o = other
You can use mathematical operators to Add, Remove, and Assign permissions
+ adds a permission to a file or directory
- Removes the permission

OK

= Sets the permission if not present above or it can override a permission

Meaning what?

Okay, I'm going to share this hack with you. Not something I should be posting here, but still:
You can use the following to prevent accidental modifications:
Don't edit those files + due dilligence = safe
Or, ya know, there's setting up local VCS, manual backup, eg cp Readme.md Readme.md.bkp_2024-11-16.

Things setting up local VCS?

Absolute mode: this method represents permissions as 3-digit octal numbers ranging from 0-7.
in symbolic you have 3 basic user representations
u = user/group
g = group
o = other
You can use mathematical operators to Add, Remove, and Assign permissions
+ adds a permission to a file or directory
- Removes the permission

OK

= Sets the permission if not present above or it can override a permission

Meaning what?

Okay, I'm going to share this hack with you. Not something I should be posting here, but still:
You can use the following to prevent accidental modifications:
Don't edit those files + due dilligence = safe
Or, ya know, there's setting up local VCS, manual backup, eg cp Readme.md Readme.md.bkp_2024-11-16.

Things setting up local VCS?
 
Things setting up local VCS?



Alternatively:
Kinda just a working example to play with

mkdir -p my-project/current my-project/snaps
nano my-project/snapshot.sh

Paste the below code and press Ctrl+O then Ctrl+X
Bash:
#! /bin/bash

printf "USE: snapshot [comment]\n\nWhere "comment" can be an optional small comment to add to backups.\n\n"

if [ ! -d "snaps" ] || [ ! -d "current" ]; then echo "Dirs \'snaps\' or \'current\' MIA. Run inside project's main dir or fix it."; exit; fi;
if [ ! -z "$1" ]; then iiComment="$1"; iiComment=$(echo "$iiComment" | tr -cd '[:alnum:]_-'); else iiComment="standard-backup"; fi;

# Obviously your own naming scheme
iiFilename="$(date +"%Y-%m-%d_%H-%M-%S")_$iiComment.tar"

# I added an error-handling stencil.
# Pragmatically, there would only be and error if you messed with something while backing up as dir checks were done above
if tar -cf "$iiFilename" current/; then
    echo "Backed up..."
    if mv "$iiFilename" snaps/; then
        echo "Moved to snaps..."
    else
       echo "Why did moving go wrong? You broke it!!!"
      exit 1
    fi
else
    echo "The tar command failed. HTF? You broke it!!!"
    exit 1
fi

chmod +x my-project/snapshot.sh

Right now you work in my-project/current/
To back it up, you cd to my-project/ and run ./snapshot.sh
You keep an eye on my-project/snaps/ and delete older or unused/unwanted snaps.
You can xz compression to snaps if you want

Note: There's probably an error or two, but you get the idea. Also, I take no responsibility for anything and don't warrant it'll work, especially with >= 1GB projects ;)
 
I feel like we need a good rcs tutorial. Or maybe I just need to spend some quality time with git.
 
Last edited:
I feel like we need a good rcs tutorial. Or maybe a just need to spend some quality time with git.

I'm more familiar with SourceForge, where it is largely just SFTP (as I recall - it has been a long minute).

I forget which one it was, but when I signed up for one of the git sites (and maybe installed a client) there was a tutorial with it that showed the basics and then got into more advanced stuff. I only did the basics and did not commit a bit of it to memory.

But, I do have 'future plans' of stuff I'd like to learn. Because of that, I have a bookmark folder for things I want to learn. Inside that folder are links like this one:


That appears to have been updated fairly recently and should get you started - and take you all the way through it. It's quite deep as compared to many other tutorials.
 
Thanks @KGIII

It really is on my to-do list to get comfortable with git - but, alas, it's nowhere near the top of said list.

Years ago, I wrote an interactive wrapper for rcs with a really clever console mode UI that handled all the day to day check in, check out, etc etc. It was for work, so it had to run under Cygwin but if I can still find it, I'm sure it will work on ash shell. That, too, is well down my to-do list.
 


Top