software freedom: compilable

software freedom: compilable


The basic skills of reading and writing are the keys to freedom with a computer that has a keyboard. Freedom is neither an independence nor an eschewing of responsibilities. Freedom is following through with a personal interest, and that inherently requires fitting with the flow of the surrounding environment.

# the computer as a recording medium

There are some objects referred to as computers, some of which have a keyboard of buttons labeled with letters and numbers. Those objects are potential mediums for writing notes, and perhaps reading those notes later.

On the other hand, the everyday person is likely better off with paper and pen for writing notes and reviewing them later. Typically, a computer is useless without its fuel, electricity; has been programmed to do what somebody else wanted to do; comes with a "Terms of Use" contract forbidding reading and modifying those programs. A computer has been all of that, in spite of having paid for it: never actually owned, a means of living out somebody else's personal interests.

Despite a computer being more fitting within a company with a computer engineering department, or at least with a tech support department, it is possible to repurpose a computer and its programs without being a computer engineer and within the bindings of its contract.

The key is to focus on its potential: the keyboard of letters and numbers. Ask around, observe, and learn how to enable the keyboard for writing with the computer. Then, use pen and paper to make notes about that, for easily referencing when encountering a computer again much later.

Writing is a means of sharing information with other people, such as with a later self. Various recording mediums complement each other rather than replace each other. However, a computer is an especially archeologically unsound recording medium, thereby a transitional blip for what is beyond itself.

# compiling is translating

With computers, a recipe is translated from one language into another, essentially a list of instructions for how to do something. When a person wants different results, that person rephrases or replaces the instructions, and then those are translated for the machine again.

In other words, a computer reads a translation of what is written by a person, but reads it only as a machine for doing rather than understanding.

Compiling instructions is what it sounds like, a gathering of different sets of instructions. With computers, compiling includes translating, thereby synonymous of building or interpreting.

Inherently, writing is an expression of the person writing, and compiling is the opportunity of instructing a machine to do something for a person. Reading and writing on a computer is an opportunity to have the computer do something for the person reading and writing.

Most helpful would be for the computer to aid in the reading and writing, by presenting views of text for reading and by repeating tasks of editing. If there was a computer program already written to do that, while abiding the restrictions of the "Terms of Use" contract, then a person could compensate the foolish purchase of the computer by repurposing it as a delegate for reading and writing.

# responsibility for personal interests

There are essentially three possibile approaches to maintaining a copy of a program, whatever it is. (a) A precompiled version has what it has. (b) Building the program from source means being able to configure it with whatever is desired. (c) Using a "package manager" to install a specific program and manage the additional packages for it adds a layer of maintenance for the package manager itself; adds mystery to the upkeep; and tends to tether the reinstallation to the Internet.

The first approach is accomplished by downloading the precompiled application, and installing it. The second approach begins the same, but then there is some assembly required according to personal interest in customizing the application.

The third approach is like the second approach, except it obfuscates itself by adding a program ("package manager") that claims to automate installation and maintenance of any other program (and of itself!) even though it always requires manual use. In other words, it is simply a different set of commands plus one more program to maintain, while insisting on access to the Internet (though there's typically an obscure method to use it without Internet access).

Obviously, independence comes with the second approach, and with it the responsibility to learn. The third approach is excessively overdoing the first approach.

# sources and customization

Much of the software is on the GNU Software listing.

Have a location for installation of the esoteric libraries and exoteric commands, such as in the home directory of the login account: "~/elec/". Have a location for downloaded source code, that perhaps is also for decompressing them and compiling them, such as the repository of incoming compilables: "~/elec/tric/".

Use ls for a listing of files, or use ls -l for lots more info about the files listed.

Download software using curl -O and then the URL, optionally with -R for original date-time, too. (Rewite that to use wget instead.)

Make a directory using mkdir and the new name. A directory is actually just a special file with a listing of files, rather than a new location. Such a listing has some other very computer-oriented information about each file in its list, like permissions and dates, so there are commands for making specific changes to a directory listing without needing to know how to keep the information consistently written.

Move a file or directory to another directory listing by using mv, the name of what to move, and the name of an existing directory. Similarly, rename a file or directory by "moving" it to a new non-existing name; that is, a name different from other names of in that directory listing.

Sources tend to be a pack of files and subdirectories globbed together as a single file usually suffixed with ".tar", and compressed in some manner indicated by an additional suffix such as ".gz", ".bz2", ".xz", or otherwise. Usually tar xf will extract from such a named file all of its contents, usually creating a new directory with a similar name as the packed file.

Within that new directory of source files, ascertain the installation prerequisites by reading the "README", "INSTALL", and "DEPENDENCIES" documents. Much of the documentation can be skimmed, because many distributions use the same commands and therefore have the same documentation.

Note the prerequisites and especially any differences from a typical installation, usually near the top or in additional files typically with UPPERCASE names. Yes, "note" means write and keep notes (someplace else, outside of the source directory) about the installation, because there will likely be a "next time" (as with anything in life), so might as well prepare for it. For example, this document is from making notes.

Also consider referencing its configure options in its help.

source/> ./configure --help

# environment for building

Confirm the necessary environment variables within the shell: PATH, CPATH, LIBRARY_PATH, PKG_CONFIG_PATH. Usually echo and the vairable name prepended by a $ will reveal it value, if any.

~/elec/tric/> echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
~/elec/tric/> echo $CPATH

~/elec/tric/> echo $LIBRARY_PATH

~/elec/tric/> echo $PKG_CONFIG_PATH

Adjust variables as needed. Assuming the installation prefix is for the esoteric libraries and exoteric commands directory "~/elec/", change to that directory and set the variables with the present working directory variable PWD. (Also supposing the precompiled ImageMagick has been installed in the repository of newspeak "~/elec/tron/" for new commands.) As aforementioned, consider saving the values in files for the executable paths and for the libraries and include files.

~/elec/> export \
> PATH\
> =$PWD/bin\
> :$PWD/tron/ImageMagick/bin\
> :$PATH \
> CPATH\
> =$PWD/include\
> :$PWD/tron/ImageMagick/include\
> :/usr/local/include\
> :/usr/include \
> LIBRARY_PATH\
> =$PWD/lib\
> :$PWD/tron/ImageMagick/lib\
> :/usr/local/lib\
> :/usr/lib \
> PKG_CONFIG_PATH\
> =$PWD/lib/pkgconfig\
> :$PWD/tron/ImageMagick/lib/pkgconfig\
> :/usr/local/lib/pkgconfig\
> :/usr/lib/pkgconfig

# building: configure, make, check, install

In general, compiling involves configuring, making, and testing before installing. Unless it says otherwise, evoke all commands from within its source directory.

Before beginning compiling, confirm the necessary environment variables. The variables for paths are colon delimited for multiple paths, and can usually be viewed with echo by prepending a $ to the name. Consider using a file to setup the variables, such as for the executable paths and for the libraries and include files.

Note that the help from the configure script (./configure --help) usually reveals the option for specifying the installation directory using --prefix with an absolute path, and offers the example of installing in the "home" directory of the login account using the HOME environment variable.

source/> ./configure --prefix=$HOME

Or, specify an existing subdirectory for keeping esoteric libraries and exoteric commands separate from everything else, because there tends to be several subdirectories.

source/> ./configure --prefix=$HOME/elec

Before making, review the configure results for any warnings or errors, because that probably indicates something else needs installing first or needs its location declared. Reconfiguring would be necessary, likely with additional options (beginning with "--") or environment variables.

When the configuration results seem fine (and after writing notes about the build progress, as aforementioned), make and test the results.

source/> make
source/> make check

Failure with make or make check will likely require reconfiguring before trying again. In that case, reset the distribution with make before reconfiguring.

source/> make distclean

Sometimes it's okay even when the check fails. When satisfied with the results of the make and checks, then install.

source/> make install

However, a system-wide installation into "/usr/local" is usually the default when --prefix is unspecified, equivalent to --prefix=/usr/local. But read the documentation for the distribution to be sure. In that case, the final installation command must be done with an administrator's account, f.e. with the sudo command.

source/> sudo make install

When installing packages some place other than system-wide, be sure to update PATH whenever an installation adds its own "bin/", CPATH when it adds "include/", and LIBRARY_PATH when it adds "lib/". Uncertain about "share/", but might try adding it to LIBRARY_PATH if it ever seems needed, because that has been seen for another circumstance. (These are GCC variables, and are used when compiling; seek more info on GCC when more info is needed.)


begin