JakeHillion/drgn
1
0
Fork 0
mirror of https://github.com/JakeHillion/drgn.git synced 2024-12-23 01:33:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
507d50c240
drgn/libdrgn/configure.ac

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

77 lines
2.6 KiB
Plaintext
Raw Normal View History

Define version in libdrgn/configure.ac Currently the drgn version number is defined in drgn.h.in, and configure and setup.py both parse it out of there. However, now that we're generating drgn.h anyways, it's easier to make configure.ac the source of truth.
2020-01-11 18:01:14 +00:00
AC_INIT([drgn], [0.0.1],
Rewrite drgn core in C The current mixed Python/C implementation works well, but it has a couple of important limitations: - It's too slow for some common use cases, like iterating over large data structures. - It can't be reused in utilities written in other languages. This replaces the internals with a new library written in C, libdrgn. It includes Python bindings with mostly the same public interface as before, with some important improvements: - Types are now represented by a single Type class rather than the messy polymorphism in the Python implementation. - Qualifiers are a bitmask instead of a set of strings. - Bit fields are not considered a separate type. - The lvalue/rvalue terminology is replaced with reference/value. - Structure, union, and array values are better supported. - Function objects are supported. - Program distinguishes between lookups of variables, constants, and functions. The C rewrite is about 6x as fast as the original Python when using the Python bindings, and about 8x when using the C API directly. Currently, the exposed API in C is fairly conservative. In the future, the memory reader, type index, and object index APIs will probably be exposed for more flexibility.
2019-03-22 23:27:46 +00:00
[https://github.com/osandov/drgn/issues],,
[https://github.com/osandov/drgn])
AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_MACRO_DIR([m4])
AC_PROG_CC
libdrgn: add register information to platform In order to retrieve registers from stack traces, we need to know what registers are defined for a platform. This adds a small DSL for defining registers for an architecture. The DSL is parsed by an awk script that generates the necessary tables, lookup functions, and enum definitions.
2019-10-18 10:03:32 +01:00
AM_INIT_AUTOMAKE([-Wall -Wno-portability foreign subdir-objects])
Rewrite drgn core in C The current mixed Python/C implementation works well, but it has a couple of important limitations: - It's too slow for some common use cases, like iterating over large data structures. - It can't be reused in utilities written in other languages. This replaces the internals with a new library written in C, libdrgn. It includes Python bindings with mostly the same public interface as before, with some important improvements: - Types are now represented by a single Type class rather than the messy polymorphism in the Python implementation. - Qualifiers are a bitmask instead of a set of strings. - Bit fields are not considered a separate type. - The lvalue/rvalue terminology is replaced with reference/value. - Structure, union, and array values are better supported. - Function objects are supported. - Program distinguishes between lookups of variables, constants, and functions. The C rewrite is about 6x as fast as the original Python when using the Python bindings, and about 8x when using the C API directly. Currently, the exposed API in C is fairly conservative. In the future, the memory reader, type index, and object index APIs will probably be exposed for more flexibility.
2019-03-22 23:27:46 +00:00
AM_PROG_AR
LT_INIT
Build Python bindings with automake I went back and forth on using setuptools or autotools for the Python extension, but I eventually settled on using only setuptools after fighting to get the two to integrate well. However, setuptools is kind of crappy; for one, it rebuilds every source file when rebuilding the extension, which is really annoying for development. automake is a better designed build system overall, so let's use that for the extension. We override the build_ext command to build using autotools and copy things where setuptools expects them.
2019-04-03 19:33:37 +01:00
AC_ARG_WITH([python],
[AS_HELP_STRING([--with-python@<:@=ARG@:>@],
[build Python bindings. ARG may be yes, no, or the
path to the Python interpreter to use. This is
normally only used by setup.py
@<:@default=no@:>@])],
[], [with_python=no])
AS_IF([test "x$with_python" != xyes && test "x$with_python" != xno],
[PYTHON=$with_python])
AM_CONDITIONAL([WITH_PYTHON], [test "x$with_python" != xno])
AM_COND_IF([WITH_PYTHON],
[AM_PATH_PYTHON([3.6])
libdrgn: check for Python development headers at configure time
2019-05-03 21:35:11 +01:00
AS_IF([test -z "$PYTHON_CPPFLAGS"],
[prog="import sysconfig
Build Python bindings with automake I went back and forth on using setuptools or autotools for the Python extension, but I eventually settled on using only setuptools after fighting to get the two to integrate well. However, setuptools is kind of crappy; for one, it rebuilds every source file when rebuilding the extension, which is really annoying for development. automake is a better designed build system overall, so let's use that for the extension. We override the build_ext command to build using autotools and copy things where setuptools expects them.
2019-04-03 19:33:37 +01:00
include = sysconfig.get_path('include')
platinclude = sysconfig.get_path('platinclude')
include_paths = [[include]]
if platinclude != include:
include_paths.append(plat_include)
print(' '.join('-I' + path for path in include_paths))"
libdrgn: check for Python development headers at configure time
2019-05-03 21:35:11 +01:00
PYTHON_CPPFLAGS=`"$PYTHON" -c "$prog"`])
AC_SUBST(PYTHON_CPPFLAGS)
AC_MSG_CHECKING([for $PYTHON development headers])
save_CPPFLAGS="$CPPFLAGS"
CPPFLAGS="$CPPFLAGS $PYTHON_CPPFLAGS"
AC_COMPILE_IFELSE([AC_LANG_SOURCE([[#include <Python.h>]])],
[AC_MSG_RESULT([yes])],
[AC_MSG_RESULT([no])
AC_MSG_ERROR(
[Could not compile test program with Python headers.
You may need to install your distribution's Python development package (e.g.,
python3-devel or python3-dev) or specify the location of the Python development
headers by setting the PYTHON_CPPFLAGS environment variable.])])
CPPFLAGS="$save_CPPFLAGS"])
Build Python bindings with automake I went back and forth on using setuptools or autotools for the Python extension, but I eventually settled on using only setuptools after fighting to get the two to integrate well. However, setuptools is kind of crappy; for one, it rebuilds every source file when rebuilding the extension, which is really annoying for development. automake is a better designed build system overall, so let's use that for the extension. We override the build_ext command to build using autotools and copy things where setuptools expects them.
2019-04-03 19:33:37 +01:00
libdrgn: build with bundled elfutils Now that we have the bundled version of elfutils, build it from libdrgn and link to it. We can also get rid of the elfutils version checks from the libdrgn code.
2019-09-04 22:40:47 +01:00
PKG_PROG_PKG_CONFIG
Add support for kdump-compressed core dumps with libkdumpfile
2019-08-02 08:00:59 +01:00
AC_ARG_WITH([libkdumpfile],
[AS_HELP_STRING([--with-libkdumpfile],
[build with support for the makedumpfile kernel
core dump format using libkdumpfile
@<:@default=auto@:>@])],
[], [with_libkdumpfile=auto])
AS_CASE(["x$with_libkdumpfile"],
[xyes], [PKG_CHECK_MODULES(libkdumpfile, [libkdumpfile])],
[xauto], [PKG_CHECK_MODULES(libkdumpfile, [libkdumpfile],
[with_libkdumpfile=yes],
[with_libkdumpfile=no])])
AM_CONDITIONAL([WITH_LIBKDUMPFILE], [test "x$with_libkdumpfile" = xyes])
AM_COND_IF([WITH_LIBKDUMPFILE], [AC_DEFINE(WITH_LIBKDUMPFILE)])
libdrgn: build with bundled elfutils Now that we have the bundled version of elfutils, build it from libdrgn and link to it. We can also get rid of the elfutils version checks from the libdrgn code.
2019-09-04 22:40:47 +01:00
AX_SUBDIRS_CONFIGURE([elfutils],
[[--enable-maintainer-mode],
[--disable-nls],
[--disable-programs],
Update to elfutils 0.178 Rebase on 0.178. The only additional change needed is to pass --disable-debuginfod to configure. Based on: 2c7c4037 elfutils.spec.in: Sync with fedora spec, remove rhel/fedora specifics. With the following patches: configure: Add --disable-programs configure: Add --disable-shared configure: Fix -D_FORTIFY_SOURCE=2 check when CFLAGS contains -Wno-error libcpu: compile i386_lex.c with -Wno-implicit-fallthrough libdwfl: add interface for attaching to/detaching from threads libdwfl: cache Dwfl_Module and Dwarf_Frame for Dwfl_Frame libdwfl: add interface for evaluating DWARF expressions in a frame
2019-12-03 20:35:37 +00:00
[--disable-shared],
[--disable-debuginfod]],
libdrgn: build with bundled elfutils Now that we have the bundled version of elfutils, build it from libdrgn and link to it. We can also get rid of the elfutils version checks from the libdrgn code.
2019-09-04 22:40:47 +01:00
[CFLAGS=-fPIC -Wno-error], [],
[--disable-static])
Rewrite drgn core in C The current mixed Python/C implementation works well, but it has a couple of important limitations: - It's too slow for some common use cases, like iterating over large data structures. - It can't be reused in utilities written in other languages. This replaces the internals with a new library written in C, libdrgn. It includes Python bindings with mostly the same public interface as before, with some important improvements: - Types are now represented by a single Type class rather than the messy polymorphism in the Python implementation. - Qualifiers are a bitmask instead of a set of strings. - Bit fields are not considered a separate type. - The lvalue/rvalue terminology is replaced with reference/value. - Structure, union, and array values are better supported. - Function objects are supported. - Program distinguishes between lookups of variables, constants, and functions. The C rewrite is about 6x as fast as the original Python when using the Python bindings, and about 8x when using the C API directly. Currently, the exposed API in C is fairly conservative. In the future, the memory reader, type index, and object index APIs will probably be exposed for more flexibility.
2019-03-22 23:27:46 +00:00
libdrgn: build with bundled elfutils Now that we have the bundled version of elfutils, build it from libdrgn and link to it. We can also get rid of the elfutils version checks from the libdrgn code.
2019-09-04 22:40:47 +01:00
AC_CONFIG_FILES([Makefile include/Makefile])
Rewrite drgn core in C The current mixed Python/C implementation works well, but it has a couple of important limitations: - It's too slow for some common use cases, like iterating over large data structures. - It can't be reused in utilities written in other languages. This replaces the internals with a new library written in C, libdrgn. It includes Python bindings with mostly the same public interface as before, with some important improvements: - Types are now represented by a single Type class rather than the messy polymorphism in the Python implementation. - Qualifiers are a bitmask instead of a set of strings. - Bit fields are not considered a separate type. - The lvalue/rvalue terminology is replaced with reference/value. - Structure, union, and array values are better supported. - Function objects are supported. - Program distinguishes between lookups of variables, constants, and functions. The C rewrite is about 6x as fast as the original Python when using the Python bindings, and about 8x when using the C API directly. Currently, the exposed API in C is fairly conservative. In the future, the memory reader, type index, and object index APIs will probably be exposed for more flexibility.
2019-03-22 23:27:46 +00:00
AC_OUTPUT
Reference in New Issue Copy Permalink