Tim et al -- FYI
There's several larger compilation changes
that have been quietly underway for quite some
time that you may want to consider:
1) switching from C -> C++
I'm mostly interested in attaching the current rpm object
ctor/dtor so that proper sub-classing can be done.
I'm also interested in using C++ exceptions to impedance
match the various embedded interpreter signal handling.
About 60-70% of RPM code compiles with
CC=g++ make
when I last looked about 1.5y ago. The starting
point will be converting rpmqv.c (i.e. main() in RPM)
to C++ so that one time initialization happens naturally.
After that the conversion will proceed transitionally on an
as needed basis, with ctor/dtor subclassing and using
the C++ exception framework to, say, throw an exception
from %{python:...} to %{perl:...} somehow.
2) eliminating RPM_I18NSTRING_TYPE and generally ignoring
data types found in metadata, looking up the type from the tag
in an internal table instead.
These changes are already in place: what remains is to
rip out the code.
3) separating build <-> install macros
RPM is currently carrying around ~500 macros Just In Case,
while installs typically use only ~50 macros.
You can add --macrosused to any rpm command to see
what macros were actually expanded when rpm exits.
Most of the macro configuration has already been split into
separate files. I've left some convenience glue (but unless I
actually rip out the glue, noone will ever change).
There are 2 means of replacing
1) specifically add additional macros with --macros colon separated paths
2) use a %{load:/path/to/file} to, say, load ruby specifc macros when needed.
I've been putting off the above for months/years, but I will likely attempt to
make
some progress on the above tasks soonishly.
73 de Jeff
The code has
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
