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