Glossary

Acronyms

Acronym	Definition	Comment
CAD	Computer Aided Design
ETA	Estimated Time of Arrival	(from aeronautic jargon) This is the date at which a given event is estimated to occur
ETE	Estimated Time Enroute	(from aeronautic jargon) This is the remaining time necessary to complete a task
LRU	Least Recently Used	A classical cache replacement policy where the entry that was least recently used is discarded when a new one is allocated
MRO	Method Research Order	The inheritance chain from the current class to its most basic base, usually `object`

Abbreviations

Some words are so heavily used in this documentation that abbreviating them greatly improve readability.

Abbreviation	Definition
dep	dependency
dir	directory
repo	repository

Regularly, open-lmake generate some messages. In order to keep such messages reasonably terse, a dedicated vocabulary is used. This vocabulary is meant to be intuitive, but a full explanation is given here.

Consider

When open-lmake finds an error and has a reasonable suggestion to fix it, it also generates an action likely to be done by the user. Wuch action are generated in a form that can be as directly copy-pasted as possible.

When such action is linked to the source versioning system, git is assumed (which is by far the most commonly used system). In case another source versioning system is used, the user must adapt the suggested action.

Dangling

A dangling file refers to an existing file with no way to generate it (i.e. no rules apply) but which is not controlled by the source versioning system.

Open-lmake considers depending on such a file an error as such dep would go against repeatability, i.e. a git push followed by a git pull in another repo would not transport said file.

Manual

A manual file refers to a file that has been modified outside open-lmake control (i.e. it is not the result of the execution of a job).

Official job

The official job of a target is the one that would be selected to generate it upon execution of the command lmake <target>. If no such job exists, the official state of such target is to not exist.

When open-lmake needs a dep for a job, it ensures its content is its official content (i.e. it is generated by its official job) for the job to be up-to-date.

A target may be generated by other means, such as written by a job as a side_target or allowed to be written by a call to lmake.target or ltarget. This does not make such target officially generated, but actually generated : open-lmake has no means to find out the right job to execute should it need to (re)generate it.

Polluted

A polluted file refers to a file that has been actually generated by a non-official job.

Quarantine

Before executing a job, open-lmake ensures its targets do not exist (unless they are incremental) to ensure repeatable executions. This may lead it to unlink such files if they have been previously generated.

However, if a target is determined to be manual (cf. above), it might contain valuable information that the user would be upset to lose.

In such cases, unless open-lmake can determine that no valuable information is present, instead of unlinking the file, it moves it to the LMAKE/quaranntine dir where it can be retrieved by the user. Open-lmake considers that there is no valuable information in 2 cases:

the file is empty
the file is identical to its previous content (typically, it has been edited, saved, but not modified)

Steady

A job is steady when it has been run, but all targets have been generated identically to the previous run, i.e. the job could have not ben run with no semantic consequences.

This may be an indication that the flow is suboptimal. Consider 2 cases:

a source file is modified, but only comments have been touched. Compilation is run as the source is modified, but the result is identical to its previous content.
a source file includes an include file (e.g. in C) or import a module (e.g. in Python), but does not actually use such include file/module.

In the first case, it is very difficult to devise a flow to avoid such compilation. A possibility would be to split the compilation process into 2 parts, the first one filtering out comments, this has generally adverse consequences (such as line numbers being altered or source file name being difficult to trace).

In the second case, the solution is probably pretty trivial : just suppress the contemplated include/import line.

Uniquify

When hard links are used and open-lmake decides that one of the link must be regenerated, sharing is no more possible.

If such a target is not incremental, it will be unlinked, regenerated and the other link will not be modified. But if such a target is incremental, it is not unlinked but a copy must be done to split the links between those that must be updated by the job execution and those the must not.

This process is called "uniquify".

A class D inherits from B and C in that order.
Both B and C inherit from a class A.
A method m is defined on A and C but not on B.
Then if m is called from an instance of D, C.m will be called and not B.m (which turns out to be A.m).

It is extensively described here.

This feature is a central point that makes python multiple inheritance easy to use and enables the class hierarchy shopping list style.

python computes the MRO in such a way as to enforce the diamond rule.

open-lmake documentation