Vast majority of software projects use a common, known build system where the steps to build and install only differ by configuration details. In rpm itself we have common macros for autotools-based projects (%configure, %make_build, %make_install), and distros have added macros to do the same for various other build systems, including language-specific ecosystems. These simplify life greatly but packagers still need to fill in specs with this redundant boilerplate for each and every project, that boilerplate just has to go away in the common case.
We should implement means to fill up the boilerplate by simply defining the project build system type, eg "Buildsystem: autotools". This would automatically populate the relevant sections with content defined in "autotools" configuration except where a section is already defined by the spec. Specifying an unknown build system would return an explicit error, ie the build systems would be "registered" by dropping a file in a known location rather than just macros defined wherever.
Actual build and install steps are common for all well-behaved packages, but configuration often has project-specific values so while a default configuration should be supplied, it needs be easy to override without reverting to all-manual spec foo. Hence we need at least #1086 for this.
Similarly there's often a need for some more or less minor tweaks to upstream build/install process, this must not require reverting to manually redefining all that. So I suppose we need pre- and post-section scripts, eg %build(post) where such manual tweaks can be placed.
Finally, there are multiple levels of possible default templates: %clean is rather universal and we already supply a default for that as a special case, and similarly %prep could quite univerally default to %autosetup -p1. Both should be overridable by buildsystem specifics though.
As an more practical example, here's an excerpt from a typical autotools project :
%prep
%autosetup
%build
%configure
%make_build
%install
%make_install
All that would simply become:
This would be defined by eg /usr/lib/rpm/buildsystem/autotools file contents which could be just a macro file looking somewhat like this:
%__autotools_configure\
%configure
%__autotools_build\
%make_build\
%__autotools_install\
%make_install
...and eg cmake definition would only really differ from that on the configure section. Python etc would use their own macros as distros have defined. This would also serve as an API to which the various language-specific build systems etc can be developed for so the definitions are cross-distro shareable.
Crucial design goals:
- minimize spec boilerplate and redundancy
- building blocks must be equally usable within templates and manual use
- minimize need for spec section override (eg provide pre/post slots for minor customization needs)
- spec override must be possible for individual sections
- no magic, what happens must be easily inspectable (rpmspec --parse etc)
Vast majority of software projects use a common, known build system where the steps to build and install only differ by configuration details. In rpm itself we have common macros for autotools-based projects (%configure, %make_build, %make_install), and distros have added macros to do the same for various other build systems, including language-specific ecosystems. These simplify life greatly but packagers still need to fill in specs with this redundant boilerplate for each and every project, that boilerplate just has to go away in the common case.
We should implement means to fill up the boilerplate by simply defining the project build system type, eg "Buildsystem: autotools". This would automatically populate the relevant sections with content defined in "autotools" configuration except where a section is already defined by the spec. Specifying an unknown build system would return an explicit error, ie the build systems would be "registered" by dropping a file in a known location rather than just macros defined wherever.
Actual build and install steps are common for all well-behaved packages, but configuration often has project-specific values so while a default configuration should be supplied, it needs be easy to override without reverting to all-manual spec foo. Hence we need at least #1086 for this.
Similarly there's often a need for some more or less minor tweaks to upstream build/install process, this must not require reverting to manually redefining all that. So I suppose we need pre- and post-section scripts, eg %build(post) where such manual tweaks can be placed.
Finally, there are multiple levels of possible default templates: %clean is rather universal and we already supply a default for that as a special case, and similarly %prep could quite univerally default to %autosetup -p1. Both should be overridable by buildsystem specifics though.
As an more practical example, here's an excerpt from a typical autotools project :
All that would simply become:
This would be defined by eg /usr/lib/rpm/buildsystem/autotools file contents which could be just a macro file looking somewhat like this:
...and eg cmake definition would only really differ from that on the configure section. Python etc would use their own macros as distros have defined. This would also serve as an API to which the various language-specific build systems etc can be developed for so the definitions are cross-distro shareable.
Crucial design goals: