debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-12-23 09:54:52 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
notmuch/lib/Makefile.local

104 lines
3.8 KiB
Text
Raw Normal View History

Makefile.local: Automatically use makefile mode We add a magic line to the beginning of each Makefile.local file to help the editor know that it should use makefile mode for editing the file, (even though the filename isn't exactly "Makefile"). Edited-by: Carl Worth <cworth@cworth.org>: Expand treatment from emacs/Makefile.local to each instance of Makefile.local.
2010-03-21 10:54:08 +01:00
# -*- makefile -*-
lib: Switch to a 3-part version number for the library interface. With a carefully documented description of how to increment the various version components.
2010-04-01 09:41:25 +02:00
# The major version of the library interface. This will control the soname.
# As such, this number must be incremented for any incompatible change to
# the library interface, (such as the deletion of an API or a major
# semantic change that breaks formerly functioning code).
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
#
# Note: We don't currently have plans to increment this at this time.
# If we *do* want to make an incompatible change to the library
# interface, we'll have to decide whether to increment this (creating
# a new soname) or to introduce symbol versioning to be able to
# provide support for both old and new interfaces without having to
# increment this.
lib: Switch to a 3-part version number for the library interface. With a carefully documented description of how to increment the various version components.
2010-04-01 09:41:25 +02:00
LIBNOTMUCH_VERSION_MAJOR = 1
# The minor version of the library interface. This should be incremented at
Increment library version to 1.3.0 For the addition of three functions: notmuch_message_get_filenames notmuch_message_tags_to_maildir_flags notmuch_message_maildir_flags_to_tags
2010-11-12 05:42:45 +01:00
# the time of release for any additions to the library interface,
# (and when it is incremented, the release version of the library should
# be reset to 0).
LIBNOTMUCH_VERSION_MINOR = 3
lib: Switch to a 3-part version number for the library interface. With a carefully documented description of how to increment the various version components.
2010-04-01 09:41:25 +02:00
# The release version the library interface. This should be incremented at
# the time of release if there have been no changes to the interface, (but
# simply compatible changes to the implementation).
LIBNOTMUCH_VERSION_RELEASE = 0
Add support for the Solaris platform Like on Mac OS X, the linker doesn't automatically resolve dependencies. Signed-off-by: Tomas Carnecky <tom@dbservice.com>
2010-04-30 21:00:24 +02:00
ifeq ($(PLATFORM),MACOSX)
Add infrastructure for building shared library on OS X. This patch adds a configure check for OS X (actually Darwin), and sets up the Makefiles to build a proper shared library on that platform. Signed-off-by: Aaron Ecay <aaronecay@gmail.com>
2010-04-12 01:44:53 +02:00
LIBRARY_SUFFIX = dylib
# On OS X, library version numbers go before suffix.
LINKER_NAME = libnotmuch.$(LIBRARY_SUFFIX)
SONAME = libnotmuch.$(LIBNOTMUCH_VERSION_MAJOR).$(LIBRARY_SUFFIX)
LIBNAME = libnotmuch.$(LIBNOTMUCH_VERSION_MAJOR).$(LIBNOTMUCH_VERSION_MINOR).$(LIBNOTMUCH_VERSION_RELEASE).$(LIBRARY_SUFFIX)
Makefile: Add library version information on OS X. This encodes the library version into the library, where the linking binary can pick it up, and the linker can even enforce mismatches in the minor release, (such as linking a binary against version 1.2 and then attempting to run it against version 1.1).
2010-04-15 01:18:19 +02:00
LIBRARY_LINK_FLAG = -dynamiclib -install_name $(SONAME) -compatibility_version $(LIBNOTMUCH_VERSION_MAJOR).$(LIBNOTMUCH_VERSION_MINOR) -current_version $(LIBNOTMUCH_VERSION_MAJOR).$(LIBNOTMUCH_VERSION_MINOR).$(LIBNOTMUCH_VERSION_RELEASE)
Add infrastructure for building shared library on OS X. This patch adds a configure check for OS X (actually Darwin), and sets up the Makefiles to build a proper shared library on that platform. Signed-off-by: Aaron Ecay <aaronecay@gmail.com>
2010-04-12 01:44:53 +02:00
else
LIBRARY_SUFFIX = so
LINKER_NAME = libnotmuch.$(LIBRARY_SUFFIX)
lib: Switch to a 3-part version number for the library interface. With a carefully documented description of how to increment the various version components.
2010-04-01 09:41:25 +02:00
SONAME = $(LINKER_NAME).$(LIBNOTMUCH_VERSION_MAJOR)
LIBNAME = $(SONAME).$(LIBNOTMUCH_VERSION_MINOR).$(LIBNOTMUCH_VERSION_RELEASE)
libnotmuch: add linker script to declare only notmuch_* symbols as global. This is closely tied to gcc and particularly gnu ld, but I guess the shared library linking code would need to be adjusted to work on a non-gnu linker anyay. I had to make a few not-obviously related changes to the lib/Makefile.local to make this work: libnotmuch_modules is defined with := and used in place of $^ (cherry picked from commit 014bf85b1c06ff49be2bde5a26433d2cf376cf70)
2011-06-22 02:25:06 +02:00
LIBRARY_LINK_FLAG = -shared -Wl,--version-script=notmuch.sym,-soname=$(SONAME)
make install: Run ldconfig or install a DT_RUNPATH in binary as appropriate. Various users were confused as to why they couldn't run notmuch immediately after "make install", (with linker errors saying that libnotmuch.so could not be found). The errors came from two different causes: 1. The user had installed to a system library directory, but had not yet run ldconfig. 2. The user had installed to some non-system directory, and had not set the LD_LIBRARY_PATH variable. With this change we fix both problems (on Linux) without the user having to do anything additional. We first use ldconfig to find the system library directories. If the user is installing to one of these, then we run ldconfig as part of "make install". For case (2) we use the -rpath and --enable-new-dtags linker options to install a DT_RUNPATH entry in the binary. This entry tells the dynamic linker where to find libnotmuch. Without the --enable-new-dtags option only a DT_RPATH option would be installed, (which has the drawback of not allowing any override with the LD_LIBRARY_PATH variable). Distributions (such as Debian and Fedora) don't want to see binaries packaged with a DT_RPATH or DT_RUNPATH entry. This should be avoided automatically as long as the packages install to standard locations, (such as /usr/lib).
2010-06-05 01:52:56 +02:00
ifeq ($(LIBDIR_IN_LDCONFIG),1)
Do not call ldconfig when building Debian package Hi, If I want to build Debian package, it fails with the following message: ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied make[1]: *** [install-lib] Error 1 The reason is that I build the package as a non-root user and make install invokes ldconfig unconditionally. The following patch contains a workaround, but I think that a more correct solution would be to check the condition LIBDIR_IN_LDCONFIG directly when make install is invoked rather than in configure as it is done now. Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
2010-06-16 16:14:18 +02:00
ifeq ($(DESTDIR),)
make install: Run ldconfig or install a DT_RUNPATH in binary as appropriate. Various users were confused as to why they couldn't run notmuch immediately after "make install", (with linker errors saying that libnotmuch.so could not be found). The errors came from two different causes: 1. The user had installed to a system library directory, but had not yet run ldconfig. 2. The user had installed to some non-system directory, and had not set the LD_LIBRARY_PATH variable. With this change we fix both problems (on Linux) without the user having to do anything additional. We first use ldconfig to find the system library directories. If the user is installing to one of these, then we run ldconfig as part of "make install". For case (2) we use the -rpath and --enable-new-dtags linker options to install a DT_RUNPATH entry in the binary. This entry tells the dynamic linker where to find libnotmuch. Without the --enable-new-dtags option only a DT_RPATH option would be installed, (which has the drawback of not allowing any override with the LD_LIBRARY_PATH variable). Distributions (such as Debian and Fedora) don't want to see binaries packaged with a DT_RPATH or DT_RUNPATH entry. This should be avoided automatically as long as the packages install to standard locations, (such as /usr/lib).
2010-06-05 01:52:56 +02:00
LIBRARY_INSTALL_POST_COMMAND=ldconfig
endif
Add infrastructure for building shared library on OS X. This patch adds a configure check for OS X (actually Darwin), and sets up the Makefiles to build a proper shared library on that platform. Signed-off-by: Aaron Ecay <aaronecay@gmail.com>
2010-04-12 01:44:53 +02:00
endif
Do not call ldconfig when building Debian package Hi, If I want to build Debian package, it fails with the following message: ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied make[1]: *** [install-lib] Error 1 The reason is that I build the package as a non-root user and make install invokes ldconfig unconditionally. The following patch contains a workaround, but I think that a more correct solution would be to check the condition LIBDIR_IN_LDCONFIG directly when make install is invoked rather than in configure as it is done now. Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
2010-06-16 16:14:18 +02:00
endif
Move installation of library from top-level to lib/Makefile.local We had a fairly ugly violation of modularity with the top-level Makefile.local isntalling everything, (even when the build commands for the library were down in lib/Makefile.local).
2010-04-01 07:47:12 +02:00
Makefile: Fix Makefiles to depend on all child Makefile fragments. We were previously maintaining two lists of the child Makefile fragments---one for the includes and another for the dependencies. So, of course, they drifted and the dependency list wasn't up to date. We fix this by adding a single subdirs variable, and then using GNU Makefile substitution to generate both the include and the dependency lists. Some side effect of this change caused the '=' assignment of the dir variable to not work anymore. I'm not sure why that is, but using ':=' makes sense here and fixes the problem.
2010-03-10 19:59:57 +01:00
dir := lib
build: Add support for non-source-directory builds. Such as: mkdir build cd build ../configure make This is implemented by having the configure script set a srcdir variable in Makefile.config, and then sprinkling $(srcdir) into various make rules. We also use vpath directives to convince GNU make to find the source files from the original source directory.
2011-03-10 00:02:42 +01:00
extra_cflags += -I$(srcdir)/$(dir) -fPIC
Implement a non-recursive make. The idea here is that every Makefile at each lower level will be an identical, tiny file that simply defers to a top-level make. Meanwhile, the Makefile.local file at each level is a Makefile snippet to be included at the top-level into a large, flat Makefile. As such, it needs to define its rules with the entire relative directory to each file, (typically in $(dir)). The local files can also append to variables such as SRCS and CLEAN for files to be analyzed for dependencies and to be cleaned.
2009-11-10 16:14:49 +01:00
Makefile: Fix dependency generation to make .d files themselves dependent. I saw this recommendation in the implementation notes for "Recursive Make Considered Harmful" and then the further recommendation for implementing the idea in the GNU make manual. The idea is that if any of the files change then we need to regenerate the dependency file before we regenerate any targets. The approach from the GNU make manual is simpler in that it just uses a sed script to fix up the output of an extra invocation of the compiler, (as opposed to the approach in the implementation notes from the paper's author which use a wrapper script for the compiler that's always invoked rather than the compiler itself).
2009-11-10 17:04:54 +01:00
libnotmuch_c_srcs = \
Makefile: Move compat sources from the client code to the library. Since the library code needs these as well.
2010-04-15 01:03:18 +02:00
$(notmuch_compat_srcs) \
lib: Add new implementation of notmuch_filenames_t The new implementation is simply a talloc-based list of strings. The former support (a list of database terms with a common prefix) is implemented by simply pre-iterating over the terms and populating the list. This should provide no performance disadvantage as callers of thigns like notmuch_directory_get_child_files are very likely to always iterate over all filenames anyway. This new implementation of notmuch_filenames_t is in preparation for adding API to query all of the filenames for a single message.
2010-11-11 08:26:31 +01:00
$(dir)/filenames.c \
Implement an internal generic string list and use it. This replaces the guts of the filename list and tag list, making those interfaces simple iterators over the generic string list. The directory, message filename, and tags-related code now build generic string lists and then wraps them in specific iterators. The real wins come in later patches, when we use these for even more generic functionality. As a nice side-effect, this also eliminates the annoying dependency on GList in the tag list.
2010-12-09 01:26:05 +01:00
$(dir)/string-list.c \
Makefile: Fix dependency generation to make .d files themselves dependent. I saw this recommendation in the implementation notes for "Recursive Make Considered Harmful" and then the further recommendation for implementing the idea in the GNU make manual. The idea is that if any of the files change then we need to regenerate the dependency file before we regenerate any targets. The approach from the GNU make manual is simpler in that it just uses a sed script to fix up the output of an extra invocation of the compiler, (as opposed to the approach in the implementation notes from the paper's author which use a wrapper script for the compiler that's always invoked rather than the compiler itself).
2009-11-10 17:04:54 +01:00
$(dir)/libsha1.c \
$(dir)/message-file.c \
lib: Move notmuch_messages_t code from query.cc to new messages.c The new object is simply a linked-list of notmuch_message_t objects, (unlike the old object which contained a couple of Xapian iterators). This works now by the query code immediately iterator over all results and creating notmuch_message_t objects for them, (rather than waiting to create the objects until the notmuch_messages_get call as we did earlier). The point of this change is to allow other instances of lists of messages, (such as in notmuch_thread_t), that are not directly related to Xapian search results.
2009-11-15 08:05:17 +01:00
$(dir)/messages.c \
Makefile: Fix dependency generation to make .d files themselves dependent. I saw this recommendation in the implementation notes for "Recursive Make Considered Harmful" and then the further recommendation for implementing the idea in the GNU make manual. The idea is that if any of the files change then we need to regenerate the dependency file before we regenerate any targets. The approach from the GNU make manual is simpler in that it just uses a sed script to fix up the output of an extra invocation of the compiler, (as opposed to the approach in the implementation notes from the paper's author which use a wrapper script for the compiler that's always invoked rather than the compiler itself).
2009-11-10 17:04:54 +01:00
$(dir)/sha1.c \
$(dir)/tags.c \
$(dir)/xutil.c
Implement a non-recursive make. The idea here is that every Makefile at each lower level will be an identical, tiny file that simply defers to a top-level make. Meanwhile, the Makefile.local file at each level is a Makefile snippet to be included at the top-level into a large, flat Makefile. As such, it needs to define its rules with the entire relative directory to each file, (typically in $(dir)). The local files can also append to variables such as SRCS and CLEAN for files to be analyzed for dependencies and to be cleaned.
2009-11-10 16:14:49 +01:00
Makefile: Fix dependency generation to make .d files themselves dependent. I saw this recommendation in the implementation notes for "Recursive Make Considered Harmful" and then the further recommendation for implementing the idea in the GNU make manual. The idea is that if any of the files change then we need to regenerate the dependency file before we regenerate any targets. The approach from the GNU make manual is simpler in that it just uses a sed script to fix up the output of an extra invocation of the compiler, (as opposed to the approach in the implementation notes from the paper's author which use a wrapper script for the compiler that's always invoked rather than the compiler itself).
2009-11-10 17:04:54 +01:00
libnotmuch_cxx_srcs = \
$(dir)/database.cc \
lib: Implement new notmuch_directory_t API. This new directory ojbect provides all the infrastructure needed to detect when files or directories are deleted or renamed. There's still code needed on top of this (within "notmuch new") to actually do that detection.
2010-01-05 22:29:23 +01:00
$(dir)/directory.cc \
Makefile: Fix dependency generation to make .d files themselves dependent. I saw this recommendation in the implementation notes for "Recursive Make Considered Harmful" and then the further recommendation for implementing the idea in the GNU make manual. The idea is that if any of the files change then we need to regenerate the dependency file before we regenerate any targets. The approach from the GNU make manual is simpler in that it just uses a sed script to fix up the output of an extra invocation of the compiler, (as opposed to the approach in the implementation notes from the paper's author which use a wrapper script for the compiler that's always invoked rather than the compiler itself).
2009-11-10 17:04:54 +01:00
$(dir)/index.cc \
$(dir)/message.cc \
$(dir)/query.cc \
$(dir)/thread.cc
libnotmuch: add linker script to declare only notmuch_* symbols as global. This is closely tied to gcc and particularly gnu ld, but I guess the shared library linking code would need to be adjusted to work on a non-gnu linker anyay. I had to make a few not-obviously related changes to the lib/Makefile.local to make this work: libnotmuch_modules is defined with := and used in place of $^ (cherry picked from commit 014bf85b1c06ff49be2bde5a26433d2cf376cf70)
2011-06-22 02:25:06 +02:00
libnotmuch_modules := $(libnotmuch_c_srcs:.c=.o) $(libnotmuch_cxx_srcs:.cc=.o)
Fix target dependencies for multiple jobs Signed-off-by: Ingmar Vanhassel <ingmar@exherbo.org>
2010-03-12 14:47:35 +01:00
Compile a static notmuch binary (but only install the shared version) The idea here is to allow a new user of notmuch to be able to run notmuch immediately after compiling, (without having to install the shared library first). This also ensures that the test suite tests the locally compiled library, and not whatever installled version of the library the dynamic linker happens to find.
2010-04-02 00:03:40 +02:00
$(dir)/libnotmuch.a: $(libnotmuch_modules)
$(call quiet,AR) rcs $@ $^
libnotmuch: add linker script to declare only notmuch_* symbols as global. This is closely tied to gcc and particularly gnu ld, but I guess the shared library linking code would need to be adjusted to work on a non-gnu linker anyay. I had to make a few not-obviously related changes to the lib/Makefile.local to make this work: libnotmuch_modules is defined with := and used in place of $^ (cherry picked from commit 014bf85b1c06ff49be2bde5a26433d2cf376cf70)
2011-06-22 02:25:06 +02:00
$(dir)/$(LIBNAME): $(libnotmuch_modules) notmuch.sym
echo $(libnotmuch_modules)
$(call quiet,CXX $(CXXFLAGS)) $(libnotmuch_modules) $(FINAL_LIBNOTMUCH_LDFLAGS) $(LIBRARY_LINK_FLAG) -o $@
notmuch.sym: lib/notmuch.h
libnotmuch: export Xapian typeinfo symbols The lack of such exporting seems to cause problems catching exceptions, as suggested by http://gcc.gnu.org/wiki/Visibility This manifested in the symbol-hiding test failing when notmuch was compile with gcc 4.4.5. On i386, this further manifested as notmuch new failing to run (crashing with an uncaught exception on first run).
2011-07-16 20:59:44 +02:00
sh lib/gen-version-script.sh $< $(libnotmuch_modules) > $@
Fix target dependencies for multiple jobs Signed-off-by: Ingmar Vanhassel <ingmar@exherbo.org>
2010-03-12 14:47:35 +01:00
lib: Switch to a 3-part version number for the library interface. With a carefully documented description of how to increment the various version components.
2010-04-01 09:41:25 +02:00
$(dir)/$(SONAME): $(dir)/$(LIBNAME)
Makefiles: Eliminate the useless quiet_* functions. With the original quiet function, there's an actual purpose (hiding excessively long compiler command lines so that warnings and errors from the compiler can be seen). But with things like quiet_symlink there's nothing quieter. In fact "SYMLINK" is longer than "ln -sf". So all this is doing is hiding the actual command from the user for no real benefit. The only actual reason we implemented the quiet_* functions was to be able to neatly right-align the command name and left-align the arguments. Let's give up on that, and just left-align everything, simplifying the Makefiles considerably. Now, the only instances of a captialized command name in the output is if there's some actually shortening of the command itself.
2010-04-06 19:00:30 +02:00
ln -sf $(LIBNAME) $@
lib: Switch to a 3-part version number for the library interface. With a carefully documented description of how to increment the various version components.
2010-04-01 09:41:25 +02:00
$(dir)/$(LINKER_NAME): $(dir)/$(SONAME)
Makefiles: Eliminate the useless quiet_* functions. With the original quiet function, there's an actual purpose (hiding excessively long compiler command lines so that warnings and errors from the compiler can be seen). But with things like quiet_symlink there's nothing quieter. In fact "SYMLINK" is longer than "ln -sf". So all this is doing is hiding the actual command from the user for no real benefit. The only actual reason we implemented the quiet_* functions was to be able to neatly right-align the command name and left-align the arguments. Let's give up on that, and just left-align everything, simplifying the Makefiles considerably. Now, the only instances of a captialized command name in the output is if there's some actually shortening of the command itself.
2010-04-06 19:00:30 +02:00
ln -sf $(LIBNAME) $@
Implement a non-recursive make. The idea here is that every Makefile at each lower level will be an identical, tiny file that simply defers to a top-level make. Meanwhile, the Makefile.local file at each level is a Makefile snippet to be included at the top-level into a large, flat Makefile. As such, it needs to define its rules with the entire relative directory to each file, (typically in $(dir)). The local files can also append to variables such as SRCS and CLEAN for files to be analyzed for dependencies and to be cleaned.
2009-11-10 16:14:49 +01:00
Move installation of library from top-level to lib/Makefile.local We had a fairly ugly violation of modularity with the top-level Makefile.local isntalling everything, (even when the build commands for the library were down in lib/Makefile.local).
2010-04-01 07:47:12 +02:00
install: install-$(dir)
lib: Fix "make install" This has been broken since the addition of the test sub-directory to our non-recursive make system.
2010-09-21 18:09:01 +02:00
# The (often-reused) $dir works fine within targets/pre-requisites,
# but cannot be used reliably within commands, so copy its value to a
# variable that is not reused.
lib := $(dir)
build: Add support for non-source-directory builds. Such as: mkdir build cd build ../configure make This is implemented by having the configure script set a srcdir variable in Makefile.config, and then sprinkling $(srcdir) into various make rules. We also use vpath directives to convince GNU make to find the source files from the original source directory.
2011-03-10 00:02:42 +01:00
install-$(dir): $(dir)/$(LIBNAME)
Makefile: Quote variables used as filenames in shell commands This allows support for filenames with spaces in them.
2011-01-26 14:29:15 +01:00
mkdir -p "$(DESTDIR)$(libdir)/"
install -m0644 "$(lib)/$(LIBNAME)" "$(DESTDIR)$(libdir)/"
ln -sf $(LIBNAME) "$(DESTDIR)$(libdir)/$(SONAME)"
ln -sf $(LIBNAME) "$(DESTDIR)$(libdir)/$(LINKER_NAME)"
mkdir -p "$(DESTDIR)$(includedir)"
build: Add support for non-source-directory builds. Such as: mkdir build cd build ../configure make This is implemented by having the configure script set a srcdir variable in Makefile.config, and then sprinkling $(srcdir) into various make rules. We also use vpath directives to convince GNU make to find the source files from the original source directory.
2011-03-10 00:02:42 +01:00
install -m0644 "$(srcdir)/$(lib)/notmuch.h" "$(DESTDIR)$(includedir)/"
make install: Run ldconfig or install a DT_RUNPATH in binary as appropriate. Various users were confused as to why they couldn't run notmuch immediately after "make install", (with linker errors saying that libnotmuch.so could not be found). The errors came from two different causes: 1. The user had installed to a system library directory, but had not yet run ldconfig. 2. The user had installed to some non-system directory, and had not set the LD_LIBRARY_PATH variable. With this change we fix both problems (on Linux) without the user having to do anything additional. We first use ldconfig to find the system library directories. If the user is installing to one of these, then we run ldconfig as part of "make install". For case (2) we use the -rpath and --enable-new-dtags linker options to install a DT_RUNPATH entry in the binary. This entry tells the dynamic linker where to find libnotmuch. Without the --enable-new-dtags option only a DT_RPATH option would be installed, (which has the drawback of not allowing any override with the LD_LIBRARY_PATH variable). Distributions (such as Debian and Fedora) don't want to see binaries packaged with a DT_RPATH or DT_RUNPATH entry. This should be avoided automatically as long as the packages install to standard locations, (such as /usr/lib).
2010-06-05 01:52:56 +02:00
$(LIBRARY_INSTALL_POST_COMMAND)
Move installation of library from top-level to lib/Makefile.local We had a fairly ugly violation of modularity with the top-level Makefile.local isntalling everything, (even when the build commands for the library were down in lib/Makefile.local).
2010-04-01 07:47:12 +02:00
Makefile: Fix dependency generation to make .d files themselves dependent. I saw this recommendation in the implementation notes for "Recursive Make Considered Harmful" and then the further recommendation for implementing the idea in the GNU make manual. The idea is that if any of the files change then we need to regenerate the dependency file before we regenerate any targets. The approach from the GNU make manual is simpler in that it just uses a sed script to fix up the output of an extra invocation of the compiler, (as opposed to the approach in the implementation notes from the paper's author which use a wrapper script for the compiler that's always invoked rather than the compiler itself).
2009-11-10 17:04:54 +01:00
SRCS := $(SRCS) $(libnotmuch_c_srcs) $(libnotmuch_cxx_srcs)
libnotmuch: build symbols list without relying on gcc -aux-info. Carl reports "gcc -aux-info notmuch.aux lib/notmuch.h" does not generate notmuch.aux for him with Debian gcc 4.6.0-8. A small modification of the original sed regular expression allows us to work directly from lib/notmuch.h, rather than preprocessing with gcc. As with most such simple regex based "parsing", this is quite sensitive to the input format, and needs that each symbol to be exported from libnotmuch should - start with "notmuch_" - be the first non-whitespace token on the line - be followed by an open parenthesis. (Cherry-picked from 51b7ab69687, with conflicts resolved by db)
2011-06-27 03:08:52 +02:00
CLEAN := $(CLEAN) $(libnotmuch_modules) $(dir)/$(SONAME) $(dir)/$(LINKER_NAME) $(dir)$(LIBNAME) libnotmuch.a notmuch.sym
Reference in a new issue Copy permalink