This commit updates the OCaml bindings and tests to use ocamlfind.
The bindings are migrated in order to use ctypes, which are now
required for MCJIT-backed Llvm_executionengine.
The tests are migrated in order to use OUnit and to verify that
the distributed META.llvm allows to build working executables.
Every OCaml toolchain invocation is now chained through ocamlfind,
which (in theory) allows to cross-compile the OCaml bindings.
The configure script now checks for ctypes (>= 0.2.3) and
OUnit (>= 2). The code depending on these libraries will be added
later. The configure script does not check the package versions
in order to keep changes less invasive.
Additionally, OCaml bindings will now be automatically enabled
if ocamlfind is detected on the system, rather than ocamlc, as it
was before.
llvm-svn: 220899
This code is based on the existing LLVM Go bindings project hosted at:
https://github.com/go-llvm/llvm
Note that all contributors to the gollvm project have agreed to relicense
their changes under the LLVM license and submit them to the LLVM project.
Differential Revision: http://reviews.llvm.org/D5684
llvm-svn: 219976
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
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
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
when building llvm. This saves quite a bit of time and space when
linking. Please report any problems via bugzilla.
Caveats:
a) This will only work on linux
b) This requires a fairly new binutils
c) This requires a fairly new gdb
llvm-svn: 184808
Makefile.config.
This is implied at the bottom of the help text of configure (besides
CC/CXX/LDFLAGS, already passed to Makefile.config).
For backward compatibility, the values of CFLAGS and CXXFLAGS defaults
to empty, overriding the default values provided by autoconf (for
example, '-g -O2' when CC=gcc').
$(CPP) is not used by our makefiles. Therefore, the value of CPP is
not passed to Makefile.config, despite beeing mentioned by 'configure
--help'.
llvm-svn: 174313
catches uses of an extremely minor and widely-available C++ extension (which
every C++ compiler I could find supports, but EDG and Clang reject in strict
mode).
The diagnosed code pattern looks like this:
struct X {
union {
struct {
int a;
int b;
} S;
};
};
llvm-svn: 174103
Makefile.config does not have the value for ENABLE_THREADS substituted as the
variable is called LLVM_ENABLE_THREADS within configure.ac. This was pointed
out by zygoloid over IRC.
llvm-svn: 174021
This adds a new --with-python option to allow configuration of the python binary
for building. If not specified, $PATH will be searched for common python binary
names (python, python2, python3). If specified, and the path is not executable,
it will attempt to search $PATH.
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
Reviewed-by: Eric Christopher <echristo@gmail.com>, Daniel Dunbar <daniel@zuster.org>
llvm-svn: 173890
In r143502, we renamed getHostTriple() to getDefaultTargetTriple()
as part of work to allow the user to supply a different default
target triple at configure time. This change also affected the JIT.
However, it is inappropriate to use the default target triple in the
JIT in most circumstances because this will not necessarily match
the current architecture used by the process, leading to illegal
instruction and other such errors at run time.
Introduce the getProcessTriple() function for use in the JIT and
its clients, and cause the JIT to use it. On architectures with a
single bitness, the host and process triples are identical. On other
architectures, the host triple represents the architecture of the
host CPU, while the process triple represents the architecture used
by the host CPU to interpret machine code within the current process.
For example, when executing 32-bit code on a 64-bit Linux machine,
the host triple may be 'x86_64-unknown-linux-gnu', while the process
triple may be 'i386-unknown-linux-gnu'.
This fixes JIT for the 32-on-64-bit (and vice versa) build on non-Apple
platforms.
Differential Revision: http://llvm-reviews.chandlerc.com/D254
llvm-svn: 172627
If the compiler is gcc, disable variants of -Wuninitialized depending
on the gcc version. This gets a lot of false positive warnings out of
the build.
Generate a new configure for the gcc -Wno-uninitialized fix.
Pick up -Wno-uninitialized from configure
Add the option -Wno[-maybe]-uninitialized as determined by configure.
llvm-svn: 172006
The Apple buildbots have been modified not to pass --target,
so they shouldn't choke on a default program prefix anymore.
Patch by Rick Foos!
llvm-svn: 164956
The Apple buildbots are set up to pass --target to configure for both
cross- and non-cross-compile builds, and the standard autoconf response
to this is to set the program prefix to '<target>-'. Until we can figure
out the proper way to handle this (don't pass --target? pass an explicit
--program-prefix=""? don't auto-populate program_prefix with target_alias?)
it's more important to keep the buildbots running.
This reverts r164633 / ba48ceb1a3802e20e781ef04ea2573ffae2ac414.
llvm-svn: 164651
to store additional flag options since too many things can
and do override CPPFLAGS. Also, this is exported, unlike CPPFLAGS
so it can be actually used elsewhere. This should enable us
to remove the AC_SUBSTs in the intel checks, but I have no way
of testing it.
llvm-svn: 161233
bits of DejaGNU.
Eric, you may want to remove the TCLSH bits from aclocal.m4 and
regenerate... I didn't want to touch the m4 file lest something
exploded.
llvm-svn: 159308
- Added HOST_ARCH to Makefile.config.in
The HOST_ARCH will be used by MCJIT tests filter, because MCJIT supported only x86 and ARM architectures now.
llvm-svn: 157015
optional library support to the llvm-build tool:
- Add new command line parameter to llvm-build: “--enable-optional-libraries”
- Add handing of new llvm-build library type “OptionalLibrary”
- Update Cmake and automake build systems to pass correct flags to llvm-build
based on configuration
Patch by Dan Malea!
llvm-svn: 156319
Also refactor the existing OProfile profiling code to reuse the same interfaces with the VTune profiling code.
In addition, unit tests for the profiling interfaces were added.
This patch was prepared by Andrew Kaylor and Daniel Malea, and reviewed in the llvm-commits list by Jim Grosbach
llvm-svn: 152620
Clang builds. The detection logic for compilers that support the warning
isn't working. Rafael is going to investigate it, but didn't want people
to have to wade through build spam until then.
llvm-svn: 151649
And fix the double-[]. It was including the [] as part of
the project name somehow, resulting in PACKAGE_TARNAME "-llvm-"
and a strange docdir default:
./configure --help | grep docdir
--docdir=DIR documentation root [DATAROOTDIR/doc/-llvm-]
llvm-svn: 146849
Some files installed by clang are not relevant for general users and we'd like
to be able to install them to a different location. This adds a new
--with-internal-prefix configure option and a corresponding PROJ_internal_prefix
makefile variable, which defaults to the standard prefix. A tool makefile
can specify that it should be installed to this internal prefix by defining
INTERNAL_TOOL.
llvm-svn: 145234
