Commit Graph

26 Commits

Author SHA1 Message Date
Peter Zotov
827f4eb6a3 [cmake] Unbreak LLVM-Config.cmake / llvm_expand_dependencies.
The algorithm for sorting libraries in topological order, as
previously implemented, had a few issues:
  * It didn't make any sense.
  * It didn't actually sort libraries in topological order.
  * It hung on some inputs, e.g. "LLVMipo".

This commit replaces the old algorithm with a straightforward port
from llvm-config.cpp.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224554 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-18 23:56:52 +00:00
Richard Smith
dadfd4f0a7 Fix misinterpretation of CMake rule found by a CMake warning (related to CMP0054).
lldb sets the variable SHARED_LIBRARY to 1, which breaks this conditional,
because older versions of CMake interpret

  if ("${t}" STREQUAL "SHARED_LIBRARY")

as meaning

  if ("${t}" STREQUAL "1")

in this case. Change the conditional so it does the right thing with both old
and new CMakes.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218542 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-26 21:33:05 +00:00
Dan Liew
b3768f6fb0 Emit a warning if llvm_map_components_to_libraries() is used noting that its
use is deprecated in favour of llvm_map_components_to_libnames()

Although message(DEPRECATION "msg") would probably be a better fit this
does nothing if CMAKE_ERROR_DEPRECATED and CMAKE_WARNING_DEPRECATED are
both off, which is the default.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214078 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-28 13:36:50 +00:00
NAKAMURA Takumi
13764f7b18 [CMake] LINK_COMPONENTS: Add also corresponding MCTargetDesc and TargetInfo as well, when target names or "nativecodegen" are specified.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212921 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-14 05:07:07 +00:00
NAKAMURA Takumi
07f95b3218 [CMake] Use target_link_libraries(INTERFACE|PRIVATE) on CMake-2.8.12 to increase opportunity for parallel build.
target_link_libraries(INTERFACE) doesn't bring inter-target dependencies in add_library,
although final targets have dependencies to whole dependent libraries.
It makes most libraries can be built in parallel.

target_link_libraries(PRIVATE) is used to shaared library.
Each dependent library is linked to the target.so, and its user will not see its grandchildren.
For example,

  - libclang.so has sufficient libclang*.a(s).
  - c-index-test requires just only libclang.so.

FIXME: lld is tweaked minimally. Adding INTERFACE in each library would be better thing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202241 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-26 06:53:16 +00:00
NAKAMURA Takumi
043cc54d6c Simplify linking to system libraries
The LLVMSupport library implementation consolidates all dependencies on
system libraries.  Move the logic gathering system libraries out of
'cmake/modules/LLVM-Config.cmake' and into 'lib/Support/CMakeLists.txt'.
Use the target_link_libraries() command there to tell CMake about the
link dependencies of the LLVMSupport implementation.  CMake will
automatically propagate this to all targets that link LLVMSupport
directly or indirectly.

We still need to build knowledge of system library dependencies into
'llvm-config'.  Store the list of libraries needed in a property on
LLVMSupport and teach 'tools/llvm-config/CMakeLists.txt' to retrieve it
from there.

Drop all calls to 'link_system_libs' and 'get_system_libs' from our
CMake code.  Replace their implementations with a warning that explains
the calls are no longer necessary.  Also drop from 'LLVMConfig.cmake'
the HAVE_* and related variables that were published there only to allow
'get_system_libs' to run outside our build process.

Contributed by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201969 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-23 06:27:04 +00:00
NAKAMURA Takumi
6eeedf33d5 Teach LLVM-Config to use logical target names (2/2)
The module still needs to collect the list of all available libraries
in order to satisfy the 'all' component.  Provide this in the package
configuration file, 'LLVMConfig.cmake', as a LLVM_AVAILABLE_LIBS
variable.  (A variable is scoped better than a global property.)
Since this won't be set for our own build, fall back to looking up the
LLVM_LIBS property to get the value when it is not set.

Contributed by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201853 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-21 14:17:07 +00:00
NAKAMURA Takumi
83782f2571 Teach LLVM-Config to use logical target names (1/2)
LLVM library names are now available as logical CMake targets both
to our own build and to application CMake code.  Replace use of
'list(FIND)' with a simple 'if(TARGET)' to determine whether a
library is available.

Contributed by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201852 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-21 14:16:52 +00:00
NAKAMURA Takumi
b1e7bec958 [CMake] Re-apply r200765, "Get rid of llvm_config() to expand dependencies."
CMake's target_link_libraries() will manage dependencies with Brad's LLVMConfig improvements.

Configuration time may be reduced by a few seconds.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201062 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-10 03:24:19 +00:00
Jordan Rose
ab70fcff6b [CMake] Deliberately get all LLVM library dependencies for standalone builds.
CMake won't expand the dependency graph for us if the dependencies are in
another project, which leads to link errors in the standalone build.
This is a refinement of r200765.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200812 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-05 00:02:42 +00:00
NAKAMURA Takumi
055e70063b [CMake] Get rid of llvm_config() to expand dependencies.
CMake's target_link_libraries() will manage dependencies.

Configuration time may be reduced by a few seconds.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200765 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-04 14:42:14 +00:00
NAKAMURA Takumi
c4c93c1493 [CMake] LLVM-Config.cmake: Split explicit_map_components_to_libraries and introduce llvm_map_components_to_libnames and llvm_expand_dependencies.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200764 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-04 14:42:04 +00:00
NAKAMURA Takumi
de2d83b9c3 [CMake] Untabify.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200644 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-02 16:46:35 +00:00
David Majnemer
6a971bb8f5 Revert "Revert "Windows: Add support for unicode command lines""
This reverts commit r192070 which reverted r192069, I forgot to
regenerate the configure scripts.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192079 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-07 01:00:07 +00:00
David Majnemer
b262556c45 Revert "Windows: Add support for unicode command lines"
This is causing MinGW bots to fail.
This reverts commit r192069.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192070 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-06 20:44:34 +00:00
David Majnemer
5a1a1856a4 Windows: Add support for unicode command lines
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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192069 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-06 20:25:49 +00:00
Chandler Carruth
8d8bdff6d7 Target a minimal terminfo library rather than necessarily a full curses
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188160 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-12 09:49:17 +00:00
Chandler Carruth
f7364d5833 Add support for linking against a curses library when available and
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187874 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-07 08:47:36 +00:00
Alexey Samsonov
ee03c949b8 Add basic zlib support to LLVM. This would allow to use compression/uncompression in selected LLVM tools.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180083 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-23 08:28:39 +00:00
Sylvestre Ledru
7aad829243 Remove the executable bit on cmake files
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179976 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-21 09:04:59 +00:00
Chandler Carruth
73c35d86b9 Add time getters to the process interface for requesting the elapsed
wall time, user time, and system time since a process started.

For walltime, we currently use TimeValue's interface and a global
initializer to compute a close approximation of total process runtime.

For user time, this adds support for an somewhat more precise timing
mechanism -- clock_gettime with the CLOCK_PROCESS_CPUTIME_ID clock
selected.

For system time, we have to do a full getrusage call to extract the
system time from the OS. This is expensive but unavoidable.

In passing, clean up the implementation of the old APIs and fix some
latent bugs in the Windows code. This might have manifested on Windows
ARM systems or other systems with strange 64-bit integer behavior.

The old API for this both user time and system time simultaneously from
a single getrusage call. While this results in fewer system calls, it
also results in a lower precision user time and if only user time is
desired, it introduces a higher overhead. It may be worthwhile to switch
some of the pass timers to not track system time and directly track user
and wall time. The old API also tracked walltime in a confusing way --
it just set it to the current walltime rather than providing any measure
of wall time since the process started the way buth user and system time
are tracked. The new API is more consistent here.

The plan is to eventually implement these methods for a *child* process
by using the wait3(2) system call to populate an rusage struct
representing the whole subprocess execution. That way, after waiting on
a child process its stats will become accurate and cheap to query.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171551 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-04 23:19:55 +00:00
Daniel Dunbar
288bc5cdd0 build/cmake: Switch to using llvm-build computed dependencies.
- I verified locally that the current dependency lists are identical.
 - This makes add_llvm_library_dependencies() a no-op. I'll remove it once this
   change passes the bots.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145355 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-29 01:31:52 +00:00
Chandler Carruth
2e1513d9cd Make my attempt to build up global deps variables actually utilize
globally scoped constructs. Also, round-trip these dependencies through
the LLVMConfig.cmake.in file thata is used by CMake-based clients of
"installed" (or built) LLVM trees.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136543 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-29 23:52:01 +00:00
Chandler Carruth
ac03e736c7 Rewrite the CMake build to use explicit dependencies between libraries,
specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.

I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.

This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.

This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.

Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.

This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136433 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-29 00:14:25 +00:00
Chris Lattner
7a2bdde0a0 Fix a ton of comment typos found by codespell. Patch by
Luis Felipe Strano Moraes!



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129558 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-15 05:18:47 +00:00
Oscar Fuentes
e7510c2e96 Rename LLVMConfig.cmake to LLVM-Config.cmake. The *Config.cmake naming
scheme is used by the functionality related to find_package.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128889 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-05 17:02:48 +00:00