Document Home | Document Index

 BLFS Build Ordering for Dependencies

The BLFS book lists lots of software, though the lists are only sometimes (e.g. for X) in the right order for building, but since not everything is needed, chasing dependencies and dependencies of dependencies will always be an issue.

Since make is about dependencies, a Makefile like the following (in a directory by itself) may be helpful:

Start with

all: <list of software actually required to be built>

then, for each software item, add

thing: <list of dependencies>
    @echo thing

and also add a similar entry for each dependency and consequential dependency (but only one entry for each item).

Then running make will list the items in the required order, or else complain about something missing which can be added. That bit is easy, but it can also report cycles, i.e. an item appears in two places in a dependency chain and hence depends on itself.

If a cycle is simple, that is, packageA depends on packageB depends on packageA, then you can build packageA without packageB, build packageB, then build packageA again, so that packageA is built twice. In this case, packageA should go into the Makefile twice with a name change (e.g. suffix -pre for the entry that does not depend on packageB). Which package to build twice may not be a free choice, and if neither way works it is bug for both packages (see how each mentions the other in the configure options (or equivalent) before deciding that this is true).

When the cycle is indirect, it is much harder to decide what to build twice, and make does not provide enough information. I have written a program mk2g (blfs_depend/mk2gr.tcl - see the Fossil repository) which shows each full dependency list that contains a cycle. Even if there are many it is then possible to identify a smaller number of identical patterns each of which leads to something that must be built twice.

mk2gr reads the same Makefile mentioned above, but looks at all target lines, not just those that will be built. If there are no cycles it prints out a possible build order - the output is in groups and it should be possible to build the items in a single group in any order.

Document Home | Document Index