[llvm-commits] CVS: llvm/autoconf/configure.ac
reid at x10sys.com
Wed Feb 15 07:30:32 PST 2006
On Wed, 2006-02-15 at 18:42 +1100, duraid at octopus.com.au wrote:
> > On Tue, 14 Feb 2006, Reid Spencer wrote:
> >> Rather than just kill this checking, I would prefer it if the aCC
> >> compiler was added to the check for supported compilers. This
> >> configuration check (that you've deleted) can prevent really bad things
> >> happening downstream.
> Not trying to be picky, but what kind of really bad things are we talking
> about? The worst thing I can imagine is that a build fails because there's
> some issue between the source/makefiles and the user's toolchain.
configure by default depends on gcc options in order to test the
capabilities of the system being configured. So, what will happen is
that you'll most likely get a misconfiguration of the HPUX system (lots
of missing capabilities) which could make it impossible to get LLVM
working on that platform.
Its possible to use another compiler for the configuration checks but
not without a lot of setup that we don't have in the configure.ac script
> > FWIW, I agree with reid.
> I did ask..! :) For now, I'll just revert it and add aCC-specific stuff
Okay, but its going to require that you ensure the aCC compiler can be
used for all the configuration tests. Please test this thoroughly before
committing it again. In particular you need to make sure that the
include/llvm/Config/config.h.in file is generated correctly for your
> (the get-rid-of-hash-tables patch is still to come)
do you mean the configure test for them? or, are you planning to rid
LLVM of hashtables altogether? If the latter, I suggest we talk a bit
about this because hashtables are the right choice in a few places.
> but the
> intention was that with a little bit of work LLVM could be made and kept
> standard-compliant and so "any good compiler" should work, in theory.
Theory is one thing, practice is another. While its *possible* to
configure for a non-GCC compliant compiler, its not easy. You need to
understand how autoconf works to do that.
> Should we insist on known-good compilers,
> abort on known-bad compilers,
yes, but lets just say "non-known-good-compilers"
> spit out scary warning messages,
warnings should only be done if there's a hope of the configuration and
compilation being done correctly. If not, the correct thing to do is
stop with a hard error. Its better the user understand the problem early
rather than later.
> or something else again?
I'm open to ideas.
> Anyway, for now I'll just revert this. Sorry guys! :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the llvm-commits