Adding pragma llvm_inline_ir.
Improved the error messages.
Append "ret void" when the return type is void
Improved the error message
in case when the string passed as llvm inline ir isn't valid llvm
assembly language.
LLVM 3.2 fix.
Add attribute AlwaysInline inside DtoInlineIRFunction.
Always generate a body for llvm_inline_ir
Also, always make llvm_inline_ir functions linkonce_odr. Because
the body is always generated when a module uses a llvm_inline_ir
function, the fact that the linker removes the function shouldn't
cause problems.
- Add an option to choose between dynamic or static library version of libconfig++
- Add an option to choose linking the runtime against dynamic or static CRT library
Only can run a quick build because of Travis time restrictions. Should
try to find a set of most-likely-to-fail command line args, maybe
"-O -gc -fPIC"?
- Relax version checking because we intend to have only a single branch
- Exclude ldfpu.asm from build with MSVC-32 (reported by huynh van sen)
- Fix FindLLVM.cmake to work on Windows again
The current code to locate libconfig++ has some trouble:
- It is located in the main CMakeList file but should be a module of its own
- It depends on pkg-config which is not available on Windows
- The returned values are not really useful therefore the library name is hard coded
This commit tries to solve these problems. For a Unix-like system there should be no difference.
Additionally, you can override the variables on the command line which is useful for builds on Windows.
Previously, it was not clear to the user if pkg-config detection failed, leading to surprises if libconfig++ actually was present on the system.
The LIBCONFIG* variables are now always cached so that they can conveniently be set from ccmake/cmake-gui.
As per the CMake docs, LANGUAGE is only to be set for files that are actually compiled. In versions prior to 2.8.7, setting it globally worked fine nevertheless.
As discussed on IRC, Bob has been the default (and recommended) way to build Tango for LDC for quite some time now. Support for it in the CMake-based build system just created a big maintenance burden for (almost) no benefits. Besides, the build system was currently broken anyway.
The makefiles seemed to support building *.bc libs for Tango though, which Bob probably doesn't, which might be worth keeping in mind.
This enables us to remove the whole ugly config file parsing hack.
Also includes some minor CMake beautifications (nobody should really be at 2.4 anymore, 2.6 is more than three years old now).
