rMake:Build Considerations

From rPath Wiki

1 Packages
2 Recipes
3 Groups
4 Redirects

rMake can be used to build four types of things: packages, recipes, groups, and redirects. The following sections provide some of the build considerations for each of these.

Packages

A developer can use package names with rmake build to build them in a single rMake build job. The developer can include a version specifier and flavor for each package if desired.

rMake handles the ordering when two or more packages are in the same build. rMake determines this order by loading the recipes, reading what packages they create, and comparing this to the build requirements for each package. rMake identifies which recipes do not require any of the other packages in their build requirements, and it builds those packages first. After these required packages are built, the other packages are built using the newly built versions of the required packages (which exist in the chroot during the rMake build).

For example, if a developer is building a new version of glib and gtk together, rMake will build glib first as a build requirement for gtk, and then rMake will build gtk using the new glib in the rMake chroot. If glib fails to build, gtk subsequently fails because rMake assumes it should use the new glib.

Recipes

A developer can specify a recipe with rmake build. rMake shadows the package for the recipe to the local rMake repository and builds the recipe there. When it is finished, rMake clones both the binaries and the source to the upstream repository from which it shadowed. This allows the developer to cook a recipe with rMake, and then commit the recipe and binaries to the upstream repository at the same time.

A developer can also build recipes that are not source checkouts, and those recipes will be committed to the project that is the current buildLabel.

Groups

A developer can build a group with rmake build --recurse --match=-group-foo. Unlike with packages and recipes, rMake builds groups individually and not as part of a larger job. This is because the groups search the respository for things they include or to which they point, and it could be potentially confusing to rMake to have another item cooked alongside a group.

For example, suppose a developer cooks group-foo, which contains a reference to package foo, together with the foo package itself. The package foo gets cooked before group-foo, and it is stored in the rMake internal repository after it is cooked. However, rMake does not know to search its internal repository for foo; it searches the same repository as if it were cooked from the command line without rMake. Therefore, the developer's efforts would result in a group-foo that contained a reference to an old foo, not the one that was just cooked.

A developer chooses rmake build --recurse --binary-search to instruct Conary to find the matching binary version of the group and rebuild the packages within that group with the flavors with which they were previously built.