Thomas Lockhart wrote:
> I believe that there is no room for -ffast-math in PostgreSQL. The
I have placed code in the spec to strip out ffast-math from the CFLAGS.
I have not as yet followed Peter's advice on exporting CFLAGS and
leaving COPT -- but that's not to say that I won't.
> > While I don't plan on following the Mandrake Way WRT repackaging our
> > tarball with bzip2, the source RPM should use whatever compression for
> > the man pages that the buildrootpolicy for that distribution supplies.
> Certainly so for the tarball. However the tarballs are delivered is how
> we should use them imho.
Exactly.
> them uncompressed in the RPM build area then they get compressed by RPM
> somewhere between installation and RPM packaging, right?
Right. Each distributor can use its own buildrootpolicy -- which
handles man page compression, executable stripping, and the like. Not an
issue -- but Mandrake historically bzip2's them.
> Not sure about the python stuff, and I don't recall doing anything in
> the past on that topic.
I thought you did up the current build way ... but I could be mistaken.
I need to see if the python interface makefile Does the Right Thing now
WRT RPM_BUILD_ROOT/DESTDIR processing. The main make stuff now acts
sanely inthe presence of RPM_BUILD_ROOT -- well, except the perl
interface, but that's a special case.
> In the past I have found that kaffe did not handle enough java code for
> my needs, but that was not for the JDBC driver. I am currently using
> jikes for my projects, and it produces *nice* code in my experience.
Jikes is open source, right? I know it is available for Red Hat (ships
with it on one of the applications CD's,IIRC.) How does a Jikes-built
JDBC sound to people? Ormaybe I don't understand the Java Way well
enough to decide. Gotta learn it a little....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11