Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA04213 for ; Thu, 4 May 2000 13:35:40 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id NAA24174; Thu, 4 May 2000 13:35:16 -0400 (EDT) To: Peter Eisentraut cc: frank , PostgreSQL Development Subject: Re: 7.0RC2 compile error ! In-reply-to: References: Comments: In-reply-to Peter Eisentraut message dated "Thu, 04 May 2000 18:24:50 +0200" Date: Thu, 04 May 2000 13:35:16 -0400 Message-ID: <24171.957461716@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200005/244 Peter Eisentraut writes: > As a short term solution, why not, it's already bad enough. But for the > future I'd like to suggest the adoption of a different principle: It's not > acceptable for parts of the tree to not be built based on the results of > configure tests. There are several reasons for that, the first and > foremost being that a configure script is not interactive. Users shouldn't > be required to monitor what flies by or, worse yet, deduce from cryptic > messages that stuff isn't going to be build at all. It currently says: *** Disabling build of libpq++ because we cannot find class string in the system's C++ header files. *** Too cryptic for you? I have a different take on the matter: it's not acceptable for a default build of Postgres to fail hard because the local system's C++ compiler is broken, libstdc++ is missing or incomplete, etc. There are too many machines that fit that description and too few people using libpq++ to justify treating libpq++ as an essential component. Perhaps we could agree on a compromise that libpq++ ought not be built at all unless specifically requested by a configure switch (eg, "--with-libpq++"). If the user actually asked for it, then failing hard is reasonable behavior. It's too late to make such a change for 7.0, I think, but we could do it for 7.1. > Silently ignoring build errors as has been suggested is equally > problematic because users will not sit in front of their terminal for > 20 minutes and scan the make output. Right, I don't like that idea either. > Also, the current configure run will fail if you > don't have a C++ compiler at all. Fail completely? I haven't tried that lately, but from the Autoconf docs I'd expect it to set CXX=gcc and then all the C++ feature tests would fail because gcc isn't there (or doesn't grok C++) --- which as things currently stand would end in our deciding not to build libpq++. Seems fairly reasonable. If configure actually falls over in that case then we've blown it... regards, tom lane