This means that relaxing the check would require (a) finding out which
of the sub-flags break our code and which don't; (b) finding out how the
answer to (a) has varied with gcc release; and (c) finding out how we
can test whether a given sub-flag is set --- are there #defines for each
of them in gcc 3?
Okay, I can see how that makes this unpractical to implement. Thanks.
The current error message is "do not put -ffast-math in CFLAGS"; does someone have an idea for a better text that doesn't imply that you actually /have/ --ffast-math in CFLAGS? It'd be good to acknowledge that it can be set implicitly, too.
And on the same subject:
On 14.10.2003, at 18:13, Peter Eisentraut wrote:
That sounds perfectly reasonable to me. Why should we develop elaborate
workarounds for compiler flags that are known to create broken code? I
also want to point out that I'm getting kind of tired of developing more
and more workarounds for sloppy Apple engineering.
Peter, you are free to consider your current environment to be the peak of perfection, but that doesn't mean that the only reason for differences between your system and others' is the sloppiness of their engineering.
I'm not aware of any Darwin-specific "workarounds" in the tree right now; the only thing close to that is the support for Apple's two-level namespaces feature. And while you can argue the relative merits of Apple's approach, the reason for its existence isn't sloppiness and the support for it that was implemented by Tom most certainly isn't a workaround.
The fact of the matter is that Mac OS X has about ten million active users, and when one of these people is looking for an RDBMS, he's gonna go for one that compiles and works great on his system, rather worrying if his platform is optimal for running PostgreSQL. Supporting this platform well is absolutely crucial to the overall adoption of pg, and even if you consider yourself to be above such pedestrian concerns, many people who have to make the business case for putting money into PostgreSQL development most definitely think otherwise.
mk
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
