From: Raja R Harinath (harinath_at_[hidden])
Date: 2000-02-29 15:27:44
"Braden N. McDaniel" <braden_at_[hidden]> writes:
> On 29 Feb 2000, Raja R Harinath wrote:
> > One problem with the "config.hpp generated by configure.in" approach
> > is that the installation is tailored to one compiler -- the compiler
> > used to configure the package. It usually isn't a problem in the C
> > world, but it definitely is a problem in the C++ world. Many people
> > often have multiple, incompatible, C++ compilers.
> This still is not an issue. Configuration is done right before compiling.
> Doing things like check what compiler is in use and modulate certain
> defines and the like is *exactly* what configure is supposed to do, and
> the need for this is by no means unique to C++ compilers.
> Distributions which are preconfigured but not compiled are, AFAICT, simply
> Not Done.
I'm not arguing that. It is just that the behaviour may be surprising
for some people. However, since people already have to deal with
multiple incompatible binary formats for multiple compilers, this may
not be too surprising.
> > So, for example, if
> > you configure with Cygwin using GNU C++, you may not be able to use
> > MSVC on the same install, and vice versa.
> I don't think autoconf supports MSVC. And besides, MSVC users are probably
> going to want project files.
Just an example. Think, instead, of using GNU C++ and SunPro C++ on
the same machine. The same logic holds.
> PS: Note that I am still not advocating an autoconf-generated config
> header, as that would mean just One More File that would need
> platform-specific versions (that is, a version particular to each platform
> not covered by autoconf). I suspect the existing config.hpp will be
> adequate and usable with autoconf.
Experience with STLPort seems to support that.
-- Raja R Harinath ------------------------------ harinath_at_[hidden] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk