summaryrefslogtreecommitdiffstats
path: root/llvm/autoconf
Commit message (Collapse)AuthorAgeFilesLines
...
* Recognize aarch64_be as valid architecture.Joerg Sonnenberger2014-10-061-2/+2
| | | | llvm-svn: 219168
* Remove unused ALL_BINDINGS configuration variable.Peter Collingbourne2014-10-031-4/+0
| | | | llvm-svn: 219035
* Delete support for AuroraUX.Rafael Espindola2014-08-141-7/+0
| | | | | | | | | auroraux.org is not resolving. I will add this to the release notes as soon as I figure out where to put the 3.6 release notes :-) llvm-svn: 215645
* [autoconf] Fixup s/3.5/3.6/. Clang's ident was 3.5.0svn in autoconf build.NAKAMURA Takumi2014-07-291-1/+1
| | | | llvm-svn: 214167
* Update LLVM version: 3.5 => 3.6Hans Wennborg2014-07-281-1/+1
| | | | | | | | | | | | | We branched 3.5, it's now time to work on 3.6. This is Sylvestre's patch from [1] plus regenerated configure file by me, and minus the release notes reset, which Sean pointed out [2] should happen later. 1. http://reviews.llvm.org/D4660 2. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140721/111137.html llvm-svn: 214131
* Drop the udis86 wrapper from llvm::sysAlp Toker2014-07-171-19/+0
| | | | | | | | This optional dependency on the udis86 library was added some time back to aid JIT development, but doesn't make much sense to link into LLVM binaries these days. llvm-svn: 213300
* Track clang r213171Alp Toker2014-07-161-20/+0
| | | | | | The clang rewriter is now a core facility. llvm-svn: 213173
* Remove path_tclsh.m4.Rafael Espindola2014-06-021-39/+0
| | | | | | Looks like it was only used by dejagnu and is now dead. llvm-svn: 210022
* GraphWriter: detect graph viewer programs at runtimeAlp Toker2014-06-021-80/+0
| | | | | | | | | | | | | | | | | | | | | | Replace the crufty build-time configure checks for program paths with equivalent runtime logic. This lets users install graphing tools as needed without having to reconfigure and rebuild LLVM, while eliminating a long chain of inappropriate compile dependencies that included GUI programs and the windowing system. Additional features: * Support the OS X 'open' command to view graphs generated by any of the Graphviz utilities. This is an alternative to the Graphviz OS X UI which is no longer available on Mountain Lion. * Produce informative log output upon failure to indicate which programs can be installed to view graphs. Ping me if this doesn't work for your particular environment. llvm-svn: 210001
* Don't hard-code ld when extracting host linker version, use ${LD} ifJoerg Sonnenberger2014-05-281-1/+1
| | | | | | it is set. llvm-svn: 209742
* AArch64/ARM64: move ARM64 into AArch64's placeTim Northover2014-05-241-9/+9
| | | | | | | | | | | | | | | This commit starts with a "git mv ARM64 AArch64" and continues out from there, renaming the C++ classes, intrinsics, and other target-local objects for consistency. "ARM64" test directories are also moved, and tests that began their life in ARM64 use an arm64 triple, those from AArch64 use an aarch64 triple. Both should be equivalent though. This finishes the AArch64 merge, and everyone should feel free to continue committing as normal now. llvm-svn: 209577
* AArch64/ARM64: remove AArch64 from tree prior to renaming ARM64.Tim Northover2014-05-241-7/+6
| | | | | | | | | | | | | | | | I'm doing this in two phases for a better "git blame" record. This commit removes the previous AArch64 backend and redirects all functionality to ARM64. It also deduplicates test-lines and removes orphaned AArch64 tests. The next step will be "git mv ARM64 AArch64" and rewire most of the tests. Hopefully LLVM is still functional, though it would be even better if no-one ever had to care because the rename happens straight afterwards. llvm-svn: 209576
* ARM64: initial backend importTim Northover2014-03-291-3/+6
| | | | | | | | | | | | This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
* Remove projects/sample.Rafael Espindola2014-03-121-1/+0
| | | | | | | | | | | | | | | As an example that was not actually being used, it suffered from a slow bitrot. The two main issues with it were that it had no cmake support and included a copy of the autoconf directory. The reality is that autoconf is not easily composable. The lack of composabilty is why we have clang options in llvm's configure. Suggesting that users include a copy of autoconf/ in their projects seems a bad idea. We are also in the process of switching to cmake, so pushing autoconf to new project is probably not what we want. llvm-svn: 203728
* Add a --enable-clang-plugin-support option to configure.Rafael Espindola2014-03-101-0/+14
| | | | | | This will replace the now badly named CLANG_IS_PRODUCTION. llvm-svn: 203471
* Now that we don't use libtool, we don't need to upgrade it :-)Rafael Espindola2014-03-051-35/+0
| | | | | | Thanks to Patrik Hägglund H for noticing it! llvm-svn: 203019
* Update comment.Eric Christopher2014-03-051-1/+1
| | | | llvm-svn: 202917
* Add patch level to llvm version in CMake and AutoconfTom Stellard2014-03-031-3/+16
| | | | | | | | | | The shared library generated by autoconf will now be called libLLVM-$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_PATCH)$(VERSION_SUFFIX).so and a symlink named libLLVM-$(VERSION_MAJOR).$(VERSION_MINOR)$(VERSION_SUFFIX).so will also be created in the install directory. llvm-svn: 202720
* [C++11] Replace autoconf --enable-cxx11 with --enable-cxx1y. TheChandler Carruth2014-03-011-8/+8
| | | | | | | | | | | | | | baseline is now C++11, and we unconditionally add -std=c++11 to the flags. This has the dim potential to break some non-GNU-compatible compiler (in terms of -std flags) using the makefiles, but those makefiles are littered with GNU-style compile flags so it would be very surprising to me for it to actually happen in practice. As always, do let me know if there is a toolchain you're using where this doesn't work, and I'll be watching the bots. llvm-svn: 202569
* [C++11] Switch autoconf and make to use C++11 by default. Now both buildChandler Carruth2014-02-281-2/+2
| | | | | | | | | | systems have the default as C++11, but retain the ability to build with C++98. Again, please restrain your enthusiasm a bit in case this needs to be reverted. =] llvm-svn: 202546
* Drop libtool from llvm.Rafael Espindola2014-02-286-14184/+11
| | | | | | | We were only using it so find the shared library extension and nm. There are simpler ways to do those things :-) llvm-svn: 202524
* With rpaths being set correctly, SHLIBPATH_VAR is not needed anymore.Rafael Espindola2014-02-281-4/+0
| | | | llvm-svn: 202510
* Add aarch64 to config.guessRenato Golin2014-02-251-0/+3
| | | | llvm-svn: 202125
* Add version, arch, system libs, and targets to Makefile.configNAKAMURA Takumi2014-02-092-6/+23
| | | | | | | | | | Teach autoconf/configure.ac to AC_SUBST several additional values in Makefile.config to make them available to Makefile code. These will be useful to generate CMake package modules from the Makefile build. Contributed by Brad King. llvm-svn: 201052
* Fix configure to find arc4random via header files.Todd Fiala2014-02-051-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ISSUE: On Ubuntu 12.04 LTS, arc4random is provided by libbsd.so, which is a transitive dependency of libedit. If a system had libedit on it that was implemented in terms of libbsd.so, then the arc4random test, previously implemented as a linker test, would succeed with -ledit. However, on Ubuntu this would also require a #include <bsd/stdlib.h>. This caused a build breakage on configure-based Ubuntu 12.04 with libedit installed. FIX: This fix changes configure to test for arc4random by searching for it in the standard header files. On Ubuntu 12.04, this test now properly fails to find arc4random as it is not defined in the default header locations. It also tweaks the #define names to match the output of the header check command, which is slightly different than the linker function check #defines. I tested the following scenarios: (1) Ubuntu 12.04 without the libedit package [did not find arc4random, as expected] (2) Ubuntu 12.04 with libedit package [properly did not find arc4random, as expected] (3) Ubuntu 12.04 with most recent libedit, custom built, and not dependent on libbsd.so [properly did not find arc4random, as expected]. (4) FreeBSD 10.0B1 [properly found arc4random, as expected] llvm-svn: 200819
* Introduce line editor library.Peter Collingbourne2014-01-311-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | This library will be used by clang-query. I can imagine LLDB becoming another client of this library, so I think LLVM is a sensible place for it to live. It wraps libedit, and adds tab completion support. The code is loosely based on the line editor bits in LLDB, with a few improvements: - Polymorphism for retrieving the list of tab completions, based on the concept pattern from the new pass manager. - Tab completion doesn't corrupt terminal output if the input covers multiple lines. Unfortunately this can only be done in a truly horrible way, as far as I can tell. But since the alternative is to implement our own line editor (which I don't think LLVM should be in the business of doing, at least for now) I think it may be acceptable. - Includes a fallback for the case where the user doesn't have libedit installed. Note that this uses C stdio, mainly because libedit also uses C stdio. Differential Revision: http://llvm-reviews.chandlerc.com/D2200 llvm-svn: 200595
* Use a heavier hammer when --enable-libcpp is passed to bypass the testsChandler Carruth2014-01-151-9/+13
| | | | | | | | | | | | | | which catch buggy versions of libstdc++. While libc++ would pass them, we don't actually update the state in the configure script to use libc++ when we pass --enable-libcpp, the logic for that is in the Makefiles. So just completely skip the library test when that configure flag is passed. Hopefully this will be enough to fix the darwin bots at last, and thanks to Duncan Smith for getting things set up so I can watch the bots myself on lab.llvm.org and see any failures! llvm-svn: 199334
* Sink the autoconf check for sufficiently modern host toolchain below theChandler Carruth2014-01-151-75/+77
| | | | | | | | | | enable flag that selects the C++ standard library to use with the host toolchain. Otherwise we end up testing the wrong config. I'm not really happy about this placement, but its pragmatic and should unblock the Apple builders. llvm-svn: 199325
* Fix a bug in r199313 where I failed to restore CXXFLAGS. Doh! NotChandler Carruth2014-01-151-0/+1
| | | | | | *quite* ready to just slam C++11 on by default. llvm-svn: 199314
* Add a check to configure that the libstdc++ selected by Clang isn'tChandler Carruth2014-01-151-10/+34
| | | | | | | | | | | | | | | | libstdc++v4.6. This is quite hard to test directly, so we test for it by checking a known missing feature in that version that was added in v4.7. This should prevent users from upgrading Clang but not GCC and hosting with a too-old GCC's libstdc++ and getting strange and hard to debug errors when we switch to C++11 by default. Also, switch several of the macros I introduced to use AC_LANG_SOURCE rather than AC_LANG_PROGRAM as we don't need configure's help writing our main function (and we don't need such a function at all for most of the tests). llvm-svn: 199313
* Remove the last weird subproject, 'privbracket'.Chandler Carruth2014-01-141-1/+0
| | | | llvm-svn: 199183
* Add checks to configure for sufficiently modern host compilers. ThisChandler Carruth2014-01-141-0/+69
| | | | | | | | | | | requires Clang 3.1 or GCC 4.7. If the compiler isn't Clang or GCC, we don't try to do any sanity checking, but this give us at least a reasonable baseline of modern compilers. Also, I'm not claiming that this is the best way to do compiler version tests. I'm happy for anyone to suggest better ways of doing this test. llvm-svn: 199182
* Ok, really, for the last time, llvm-gcc is dead Jim.Chandler Carruth2014-01-141-11/+0
| | | | | | | | | Also, so is stacker, llvm-tv, etc. Wow. But will someone please fess up to what projects/privbracket is and why our autoconf build supports it? llvm-svn: 199179
* llvm-gcc is dead. REALLY. IT'S DEAD JIM.Chandler Carruth2014-01-141-2/+2
| | | | llvm-svn: 199178
* Remove the test for endianness in configure.ac and regenerate.Eric Christopher2014-01-091-3/+0
| | | | llvm-svn: 198825
* Update the copyright credits -- Happy new year 2014!NAKAMURA Takumi2014-01-011-2/+2
| | | | | FIXME: Dragonegg may be updated at non-trivial changes. llvm-svn: 198274
* Update to reflect the next release.Bill Wendling2013-11-201-2/+2
| | | | llvm-svn: 195235
* [autoconf] Prune "runtime" stuff in configure, corresponding to r191835.NAKAMURA Takumi2013-11-111-1/+0
| | | | | | | config.status: executing runtime/Makefile commands autoconf/install-sh: runtime/Makefile does not exist. llvm-svn: 194376
* Update so that it uses the `-V' command line option and supports Python 3.x.Bill Wendling2013-10-121-3/+4
| | | | llvm-svn: 192527
* Revert "Revert "Windows: Add support for unicode command lines""David Majnemer2013-10-071-0/+1
| | | | | | | This reverts commit r192070 which reverted r192069, I forgot to regenerate the configure scripts. llvm-svn: 192079
* Revert "Windows: Add support for unicode command lines"David Majnemer2013-10-061-1/+0
| | | | | | | This is causing MinGW bots to fail. This reverts commit r192069. llvm-svn: 192070
* Windows: Add support for unicode command linesDavid Majnemer2013-10-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The MSVCRT deliberately sends main() code-page specific characters. This isn't too useful to LLVM as we end up converting the arguments to UTF-16 and subsequently attempt to use the result as, for example, a file name. Instead, we need to have the ability to access the Unicode command line and transform it to UTF-8. This has the distinct advantage over using the MSVC-specific wmain() function as our entry point because: - It doesn't work on cygwin. - It only work on MinGW with caveats and only then on certain versions. - We get to keep our entry point as main(). :) N.B. This patch includes fixes to other parts of lib/Support/Windows s.t. we would be able to take advantage of getting the Unicode paths. E.G. clang spawning clang -cc1 would want to give it Unicode arguments. Reviewers: aaron.ballman, Bigcheese, rnk, ruiu Reviewed By: rnk CC: llvm-commits, ygao Differential Revision: http://llvm-reviews.chandlerc.com/D1834 llvm-svn: 192069
* Remove error output from configure if CFLAGS is set (r174313).Patrik Hagglund2013-09-241-2/+2
| | | | | | This fixes PR16724. llvm-svn: 191289
* Fix for executing AutoRegen.sh. Revert a part of r187209.Patrik Hagglund2013-09-131-0/+16
| | | | | | | | | | | | | | | | | Since r187209, which modified ltdl.m4, I was unable to execute AutoRegen.sh, getting: ../configure:10779: error: possibly undefined macro: AC_LTDL_FUNC_ARGZ This commit re-adds AC_LTDL_FUNC_ARGZ to ltdl.m4, as a quick fix. For me, this corresponds to the configure file currently checked in. (However, the ltdl library seems to be unused since r74924 in 2009, except for the use of the LTDL_SHLIB_EXT macro in bugpoint(?). Therefore, the right solution seems to try to get rid of the local ltdl.m4 file, specified by autoconf/README.TXT.) llvm-svn: 190677
* [conf] Add config variable to disable crash related overrides.Daniel Dunbar2013-08-301-13/+30
| | | | | | | | | | | | | | | | | | | | | - We do some nasty things w.r.t. installing or overriding signal handlers in order to improve our crash recovery support or interaction with crash reporting software, and those things are not necessarily appropriate when LLVM is being linked into a client application that has its own ideas about how to do things. This gives those clients a way to disable that handling at build time. - Currently, the code this guards is all Apple specific, but other platforms might have the same concerns so I went for a more generic configure name. Someone who is more familiar with library embedding on Windows can handle choosing which of the Windows/Signals.inc behaviors might make sense to go under this flag. - This also fixes the proper autoconf'ing of ENABLE_BACKTRACES. The code expects it to be undefined when disabled, but the autoconf check was just defining it to 0. llvm-svn: 189694
* Autoconf: The Clang ARC migrator now depends on the static analyzer.Jordan Rose2013-08-221-1/+6
| | | | | | | | | I don't actually have a version of autoconf so I edited configure directly as well. It's copy-pasted so I think there was little margin for error. See also Clang-side dependency graph changes. llvm-svn: 189026
* Recognize NetBSD's terminfo implementation.Joerg Sonnenberger2013-08-171-1/+1
| | | | llvm-svn: 188606
* Remove all checking for the various terminfo headers (term.h andChandler Carruth2013-08-121-5/+0
| | | | | | | | | | | | | | | | curses.h). Finding these headers is next to impossible. For example, on Debian systems libtinfo-dev provides the terminfo reading library we want, but *not* term.h. For the header, you have to use libncurses-dev. And libncursesw-dev provides a *different* term.h in a different location! These headers aren't worth it. We want two functions the signatures of which are clearly spec'ed in sys-v and other documentation. Just declare them ourselves and call them. This should fix some debian builders and provide better support for "minimal" debian systems that do want color autodetection. llvm-svn: 188165
* Target a minimal terminfo library rather than necessarily a full cursesChandler Carruth2013-08-121-14/+14
| | | | | | | | | | | | | | | | | | | | library for color support detection. This still will use a curses library if that is all we have available on the system. This change tries to use a smaller subset of the curses library, specifically the subset that is on some systems split off into a separate library. For example, if you install ncurses configured --with-tinfo, a 'libtinfo' is install that provides just the terminfo querying functionality. That library is now used instead of curses when it is available. This happens to fix a build error on systems with that library because when we tried to link ncurses into the binary, we didn't pull tinfo in as well. =] It should also provide an easy path for supporting the NetBSD libterminfo library, but as I don't have access to a NetBSD system I'm leaving adding that support to those folks. llvm-svn: 188160
* Add support for linking against a curses library when available andChandler Carruth2013-08-071-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | using it to detect whether or not a terminal supports colors. This replaces a particularly egregious hack that merely compared the TERM environment variable to "dumb". That doesn't really translate to a reasonable experience for users that have actually ensured their terminal's capabilities are accurately reflected. This makes testing a terminal for color support somewhat more expensive, but it is called very rarely anyways. The important fast path when the output is being piped somewhere is already in place. The global lock may seem excessive, but the spec for calling into curses is *terrible*. The whole library is terrible, and I spent quite a bit of time looking for a better way of doing this before convincing myself that this was the fundamentally correct way to behave. The damage of the curses library is very narrowly confined, and we continue to use raw escape codes for actually manipulating the colors which is a much sane system than directly using curses here (IMO). If this causes trouble for folks, please let me know. I've tested it on Linux and will watch the bots carefully. I've also worked to account for the variances of curses interfaces that I could finde documentation for, but that may not have been sufficient. llvm-svn: 187874
OpenPOWER on IntegriCloud