-
Notifications
You must be signed in to change notification settings - Fork 376
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Implement declarative buildsystem support
Remove endless boilerplate to perform the same steps in each package by just declaring which kind of buildsystem the package uses using the new BuildSystem: spec tag. Buildsystem macros are just regular parametric macros which can be invoked manually from specs too, which should help with reuse and handling complicated cases. As such, this will only work for simple and/or "perfect" upstream projects of course. In reality many/most packages need further tweaking, but this can now be easily done with the new append/prepend modes of the build scriptlets, and declaratively passed options to specific sections. Add automake upstream amhello-1.0.tar.gz as an test-case of a rather hands-free build with added distro specific doc. Fixes: #1087
- Loading branch information
Showing
11 changed files
with
347 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,115 @@ | ||
--- | ||
layout: default | ||
title: rpm.org - Declarative builds | ||
--- | ||
|
||
# Declarative builds | ||
|
||
Most software follows common patterns as to how it should be prepared and | ||
built, such as the classic `./configure && make && make install` case. | ||
In a spec, these all go to their own sections and when combined with | ||
the steps to unpack sources, it creates a lot of boilerplate that is | ||
practically identical across a lot of specs. With the odd tweak to | ||
this or that detail for distro preferences and the like. To reduce | ||
the repetitive boilerplate, rpm >= 4.20 adds support for a declarative | ||
build system mechanism where these common steps can be defined centrally | ||
per each build system. Packagers then only need to declare which build | ||
system they use, and optionally supply additional switches and/or | ||
arguments for the steps where needed. | ||
|
||
## Spec usage | ||
|
||
In the most simple case, a spec will have an buildsystem declaration such | ||
as `BuildSystem: cmake` and no manually specified build scripts at all. | ||
However it's common to have to manually tweak a thing or two. There are | ||
several ways how to accomplish this, what's appropriate depends on the | ||
case. | ||
|
||
1) Use append and/or prepend as necessary. Need to delete a file after | ||
the install step? Add a `%install -a` section with the appropriate `rm`. | ||
Need to `sed` something just before the build step? Add a `%build -p` | ||
section with the necessary steps. | ||
|
||
2) Another very common need is to pass extra arguments to the build | ||
commands, build configuration in particular. This is done with the | ||
BuildOption tag, which can appear arbitrary number of times | ||
in the spec for each section. | ||
|
||
``` | ||
BuildOption(<section>): <option string> | ||
``` | ||
|
||
without the parenthesis defaults to configuration. In other words, | ||
these two lines are exactly equivalent: | ||
|
||
``` | ||
BuildOption: --enable-fu | ||
BuildOption(conf): --enable-fu | ||
``` | ||
|
||
Passing these per-section options to the actual buildsystem of the | ||
package is the responsibility of the buildsystem specific macros. | ||
|
||
3) Complex packages can have things like multiple build systems, in | ||
which case you might want to invoke the macros manually, eg. | ||
|
||
``` | ||
%buildsystem_autotools_build | ||
cd python | ||
%buildsystem_python_build | ||
``` | ||
|
||
## Supporting new build systems | ||
|
||
Supporting new build system types is just a matter of declaring a few | ||
macros for the build scriptlet sections relevant to the build system. | ||
|
||
Scriptlet | Mandatory | Buildsystem macro | ||
------------------------------------------- | ||
`%prep` | No | `%buildsystem_name_prep` | ||
`%conf` | Yes | `%buildsystem_name_conf` | ||
`%generate_buildrequires` | No | `%buildsystem_name_generate_buildrequires` | ||
`%build` | Yes | `%buildsystem_name_build` | ||
`%install` | Yes | `%buildsystem_name_install` | ||
`%check` | No | `%buildsystem_name_check` | ||
`%clean` | No | `%buildsystem_name_clean` | ||
|
||
Replace "name" with the buildsystem name, eg `%buildsystem_cmake_build`. | ||
When BuildSystem: tag is set, these automatically populate the corresponding | ||
spec section, unless the spec manually overrides it. All buildsystem | ||
macros are required to be parametric to have enforceable semantics. | ||
|
||
For example, supporting the classic autotools case could be built on top | ||
of existing helper macros: | ||
``` | ||
%buildsystem_autotools_conf() %configure | ||
%buildsystem_autotools_build() %make_build | ||
%buildsystem_autotools_install() %make_install | ||
``` | ||
|
||
## Global defaults | ||
|
||
While the actual steps to build and install obviously differ greatly among | ||
different buildsystems, they still typically share a lot of common steps. | ||
Namely, unpacking sources, applying patches and cleaning up at the end. | ||
To avoid each buildsystem having to declare a `%prep` to automatically | ||
perform the same common duties, with inevitable subtle differences and | ||
bugs, rpm additionally supports global default actions for all scriptlets | ||
supported by the buildsystem mechanism. These defaults, if defined, | ||
are only called if there's no corresponding buildsystem specific macro | ||
defined. | ||
|
||
Rpm ships with a default to perform `%autosetup -p1` in `%prep`, | ||
so unless a buildsystem has an unusual source preparation sequence | ||
source preparation will "just work". Passing extra arguments to a section | ||
is exactly the same with defaults and buildsystem specific macros, so | ||
the user does not need to know which one is being used. For example, | ||
if the upstream source doesn' version their source release directory, | ||
it can simply be supplied with the following in the spec: | ||
|
||
``` | ||
BuildOption(prep): -n %{name} | ||
``` | ||
|
||
Note that the defaults are only meant for upstream and distro-level | ||
customization only, do not override them for your own purposes! |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
%bcond_with alt | ||
|
||
Name: amhello | ||
Version: 1.0 | ||
Source: amhello-%{version}.tar.gz | ||
License: GPLv2 | ||
Summary: Autotools example | ||
BuildSystem: autotools | ||
|
||
%if %{with alt} | ||
BuildOption: --program-prefix=alt- | ||
BuildOption(install): DESTDIR=${RPM_BUILD_ROOT}/alt | ||
Release: 1alt | ||
%else | ||
Release: 1 | ||
%endif | ||
|
||
%description | ||
%{summary} | ||
|
||
%build -a | ||
cat << EOF > README.distro | ||
Add some distro specific notes. | ||
EOF | ||
|
||
%files | ||
%doc README.distro | ||
%if %{with alt} | ||
/alt/%{_bindir}/alt-hello | ||
/alt/%{_docdir}/%{name} | ||
%else | ||
%{_bindir}/hello | ||
%{_docdir}/%{name} | ||
%endif |
Oops, something went wrong.