On Wed, 2006-02-15 at 18:42 +1100, [EMAIL PROTECTED] 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 right now. > > > FWIW, I agree with reid. > > I did ask..! :) For now, I'll just revert it and add aCC-specific stuff > later 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 HPUX system. > (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, yes. > 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! :) Thanks. Reid
signature.asc
Description: This is a digitally signed message part
_______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
