mingw spec file generation with script (like kmodtool)

[Erik van Pienbroek]

Farkas Levente schreef op wo 06-07-2011 om 23:51 [+0200]:
> i can't solve this f***n debug define so it's always have to add to the
> spec file:
> ----------------------------
> %define __debug_install_post %{mingw_debug_install_post}
> ----------------------------

Does it work if you hide this line behind the mingwtool macro (so that
this line gets added by the mingwtool) ? 

> the magic is hidden into mingwtool which generate the rest of the spec
> file with this two lines:
> ----------------------------
> %global mingwtool sh /usr/lib/rpm/mingwtool
> %{expand:%(%{mingwtool} --br "gcc" --doc "AUTHORS CHANGES COPYING
> README" 2>/dev/null)}
> ----------------------------

As it is now, I see a major issue with this approach. That is that the
mingwtool isn't part of a default Fedora/EPEL buildroot. So if you try
to build such a package in mock/koji it will fail because it doesn't
know where to find the mingwtool. Even if you add a BR: mingw-filesystem
(or wherever the mingwtool will be bundled with) then the build will
still fail because mock/koji only processes the BuildRequires tags
once. 

With this approach the build tool (mock/koji) has to process the .spec
file tags once to find the package containing the mingwtool, install
this package and parse the .spec file another time with the mingwtool
macro expanded. However, such a feature isn't implemented at the moment
in mock/koji..

There are two solutions to this problem. Unfortunately each one comes
with its own set of drawbacks:
(1). Have the package containing the mingwtool become part of the
default Fedora/EPEL buildroot
(2). Bundle the mingwtool with every package which needs the mingwtool
to build

The downside of (1) is that it requires the approval of the Fedora and
EPEL authorities and isn't portable among other RPM-based distributions
(say: the OpenSuSE build system).

The downside of (2) is that it will lead to a maintenance nightmare as
every mingw package will have to bundle it's own copy of mingwtool.
Whenever a fix needs to be applied to mingwtool, every package
containing mingwtool has to be updated. This makes it very hard to keep
track of which package contains which version of mingwtool etc..

The kmodtool seems to be part of the package redhat-rpm-config which is
in the default buildroot. That's why building kernel modules work fine
in mock/koji.


> the useful parameters for the shell script are:
> --enable-* (or --with-*) and --disable-* (or --without-*)
> which can turn on and off some feature which are:
> - mingw32 to generate mingw32 subpackages default: on
> - mingw64 to generate mingw64 subpackages default: on
> - darwinx to generate darwinx subpackages default: off
> - static  to generate static  subpackages default: on
> - debug   to generate debug   subpackages default: on
> 
> --br BuildRequires mingw32/64 packages
> --doc additional documentation files to the main package
> not yet implemented:
> --req Requires for mingw32/64 packages for the subpackage
> --prov Provides for mingw32/64 packages for the subpackage
> --obs Obsoletes for mingw32/64 packages for the subpackage
> 
> eg:
> %{expand:%(%{mingwtool} --disable-mingw64 --disable-static --br "gcc
> gcc-c++" --doc "AUTHORS CHANGES COPYING README" 2>/dev/null)}
> - don't build mingw64 and static subpackages
> - add BuildRequires: mingw32-gcc mingw32-gcc-c++
> - add the above files to mingw32-libogg %doc section
> 

This sure looks interesting. You may want to split the expand
instruction over multiple lines so that it's better readable.

Did you also take care of the situation that not all mingw-* packages
are also available on darwinx-* ? For example, the package win-iconv is
only available for Win32 and Win64. Perhaps you could create some kind
of exception-list inside the mingwtool which contains a list of all such
special-case packages.

Could you also send the mingwtool script to this mailing list once your
okay with it so we can take a look at it?

Kind regards,

Erik van Pienbroek