projects rely upon llvm-gcc, the LLVM test suite, and poolalloc. This ensures
that the aforementioned projects have their object trees created first so that
other projects can find their object trees when they themselves are configured.
llvm-svn: 98998
The MicroBlaze is a highly configurable 32-bit soft-microprocessor for
use on Xilinx FPGAs. For more information see:
http://www.xilinx.com/tools/microblaze.htmhttp://en.wikipedia.org/wiki/MicroBlaze
The current LLVM MicroBlaze backend generates assembly which can be
compiled using the an appropriate binutils assembler.
llvm-svn: 96969
Comes in two parts:
1. Use --with-clang=path/to/clang/compiler to select an installed clang, or
--with-built-clang to have the makefiles use the clang which will be built
as the LLVM capable compiler. If neither is given, --with-built-clang will
be used if the Clang sources are checked out into the standard location
(tools/clang).
2. Use --with-llvmcc={llvm-gcc,clang,none} to specify which LLVM capable
compiler to use. If not given, then llvm-gcc will be used if available,
otherwise Clang.
Makefile support still to come.
Eric, Doug, Chris, seem reasonable?
llvm-svn: 96934
--enable-shared configure flag to have the tools linked shared. (2.7svn is just
$(LLVMVersion) so it'll change to "2.7" in the release.) Always link the
example programs shared to test that the shared library keeps working.
On my mac laptop, Debug libLLVM2.7svn.dylib is 39MB, and opt (for example) is
16M static vs 440K shared.
Two things are less than ideal here:
1) The library doesn't include any version information. Since we expect to break
the ABI with every release, this shouldn't be much of a problem. If we do
release a compatible 2.7.1, we may be able to hack its library to work with
binaries compiled against 2.7.0, or we can just ask them to recompile. I'm
hoping to get a real packaging expert to look at this for the 2.8 release.
2) llvm-config doesn't yet have an option to print link options for the shared
library. I'll add this as a subsequent patch.
llvm-svn: 96559
HAVE_{BI,STD,FWD}_ITERATOR and HAVE_NAMESPACES were not used in the code.
bison and flex are no longer used.
CAN_DLOPEN_SELF was never used either.
AC_PROG_LIBTOOL is not needed since we don't use libtool, we only need the
libltdl checks for dlopen.
Add check for AR, it used to be done by AC_PROG_LIBTOOL.
AC_TYPE_SIGNAL is deprecated, follow autoupdate's suggestion and replace with
void.
Remove unused m4 files.
Configure can now be generated using autoconf 2.65 too, without any warnings!
llvm-svn: 94534
same effect that "host-only" used to have, but can be combined with other
targets. host-only is still available as a synonym but no longer documented.
llvm-svn: 82634
A include/llvm/ADT/iterator.cmake
U autoconf/configure.ac
--- Reverse-merging r80161 into '.':
U cmake/config-ix.cmake
--- Reverse-merging r80171 into '.':
U Makefile
--- Reverse-merging r80173 into '.':
U configure
U include/llvm/Config/config.h.in
--- Reverse-merging r80180 into '.':
A include/llvm/ADT/iterator.h.in
Despite common miscomceptions, iterator.h is alive and well. It broke the build
bots for several hours. And yet no one bothered to look at them.
Gabor and Doug, please review your changes and make sure that they actually
build before resubmitting them.
llvm-svn: 80197
so get rid of this monstrosity. iterator.h.in is scheduled for deletion in my working copy,
but I wait till I see that configure gets regenerated, as it depends on it. I'll commit
then.
There are still some AC_* tests in the configure.ac dealing with iterators, those can
be zapped probably too.
llvm-svn: 80147
- I did not actually remove the configure test itself, someone who can
regenerate configure should do this (see FIXME in autoconf/configure.ac)
llvm-svn: 79881
