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

93 lines
3.1 KiB
Text
Raw Normal View History

emacs: Use makefile-gmake-mode in Makefile*s Use `makefile-gmake-mode' instead of `makefile-mode' because the former also highlights ifdef et al. while the latter does not. "./Makefile.global" and one "Makefile.local" failed to specify any major mode at all but doing so is necessary because Emacs does not automatically figure out that these are Makefiles (of any flavor).
2020-08-08 13:49:49 +02:00
# -*- makefile-gmake -*-
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
build: switch to hiding libnotmuch symbols by default The dynamic generation of the linker version script for libnotmuch exports has grown rather complicated. Reverse the visibility control by hiding symbols by default using -fvisibility=hidden, and explicitly exporting symbols in notmuch.h using #pragma GCC visibility. (We could also use __attribute__ ((visibility ("default"))) for each exported function, but the pragma is more convenient.) The above is not quite enough alone, as it would "leak" a number of weak symbols from Xapian and C++ standard library. Combine it with a small static version script that filters out everything except the notmuch_* symbols that we explicitly exposed, and the C++ RTTI typeinfo symbols for exception handling. Finally, as the symbol hiding test can no longer look at the generated symbol table, switch the test to parse the functions from notmuch.h.
2017-05-10 21:42:11 +02:00
dir := lib
# The (often-reused) $dir works fine within targets/prerequisites,
# but cannot be used reliably within commands, so copy its value to a
# variable that is not reused.
lib := $(dir)
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)
lib: make notmuch shared library install_name be full path on Mac OS X The install_name of libnotmuch.dylib on Mac OS X is what is written into a program that links against it. If it is just the name of the shared library file, as opposed to the full path, the program won't be able to find it when it runs and will abort. Instead, the install_name should be the full path to the shared library (in its final installed location). Why does Notmuch work without this patch when installed via Homebrew? The answer is twofold. One, /usr/local/lib is a special location in which the dynamic linker will look by default to find shared libraries. Homebrew highly recommends installing to /usr/local, and, assuming it has been configured this way, the Notmuch library will end up installed in /usr/local/lib, and the dynamic linker will find it. Two, Homebrew globally corrects all install names in dynamically shared libraries and binaries for each package it installs. So, even if the install names in a package's binaries and libraries are incorrect, Homebrew corrects them automatically, and no one ever knows. Why does Notmuch work without this patch when installed via MacPorts? The answer is that MacPorts applies a patch just like this patch to fix the same problem.
2015-03-04 23:32:49 +01:00
LIBRARY_LINK_FLAG = -dynamiclib -install_name $(libdir)/$(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)
build: fix out-of-tree builds, again Broken, again, by yours truly in bc11759dd1fd ("build: switch to hiding libnotmuch symbols by default"). Reference notmuch.sym via $(srctree).
2017-09-10 13:56:16 +02:00
LIBRARY_LINK_FLAG = -shared -Wl,--version-script=$(srcdir)/$(lib)/notmuch.sym,-soname=$(SONAME) $(NO_UNDEFINED_LDFLAGS)
Support OpenBSD OpenBSD's build flags are identical to FreeBSD, except that libraries need to be explicitly linked against libc. No code changes are necessary. From: Cody Cutler <ccutler@csail.mit.edu>
2012-10-24 23:43:28 +02:00
ifeq ($(PLATFORM),OPENBSD)
LIBRARY_LINK_FLAG += -lc
endif
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
build: switch to hiding libnotmuch symbols by default The dynamic generation of the linker version script for libnotmuch exports has grown rather complicated. Reverse the visibility control by hiding symbols by default using -fvisibility=hidden, and explicitly exporting symbols in notmuch.h using #pragma GCC visibility. (We could also use __attribute__ ((visibility ("default"))) for each exported function, but the pragma is more convenient.) The above is not quite enough alone, as it would "leak" a number of weak symbols from Xapian and C++ standard library. Combine it with a small static version script that filters out everything except the notmuch_* symbols that we explicitly exposed, and the C++ RTTI typeinfo symbols for exception handling. Finally, as the symbol hiding test can no longer look at the generated symbol table, switch the test to parse the functions from notmuch.h.
2017-05-10 21:42:11 +02:00
extra_cflags += -I$(srcdir)/$(dir) -fPIC -fvisibility=hidden
extra_cxxflags += -fvisibility-inlines-hidden
Prefix lib/notmuch.h and lib/gen-version-script.sh with $(srcdir) lib/notmuch.h and lib/gen-version-script.sh couldn't have been found when building out of sources directory.
2011-10-23 16:44:01 +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
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)/message-file.c \
lib: factor out message-id parsing to separate file. This is really pure C string parsing, and doesn't need to be mixed in with the Xapian/C++ layer. Although not strictly necessary, it also makes it a bit more natural to call _parse_message_id from multiple compilation units.
2017-06-04 14:32:26 +02:00
$(dir)/message-id.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 \
lib/cli: add library API / CLI for compile time options This is intentionally low tech; if we have more than two options it may make sense to build up what infrastructure is provided.
2016-03-22 11:54:45 +01:00
$(dir)/built-with.c \
lib: private string map (associative array) API The choice of array implementation is deliberate, for future iterator support
2016-06-13 03:05:49 +02:00
$(dir)/string-map.c \
reindex: drop notmuch_param_t, use notmuch_indexopts_t instead There are at least three places in notmuch that can trigger an indexing action: * notmuch new * notmuch insert * notmuch reindex I have plans to add some indexing options (e.g. indexing the cleartext of encrypted parts, external filters, automated property injection) that should properly be available in all places where indexing happens. I also want those indexing options to be exposed by (and constrained by) the libnotmuch C API. This isn't yet an API break because we've never made a release with notmuch_param_t. These indexing options are relevant in the listed places (and in the libnotmuch analogues), but they aren't relevant in the other kinds of functionality that notmuch offers (e.g. dump/restore, tagging, search, show, reply). So i think a generic "param" object isn't well-suited for this case. In particular: * a param object sounds like it could contain parameters for some other (non-indexing) operation. This sounds confusing -- why would i pass non-indexing parameters to a function that only does indexing? * bremner suggests online a generic param object would actually be passed as a list of param objects, argv-style. In this case (at least in the obvious argv implementation), the params might be some sort of generic string. This introduces a problem where the API of the library doesn't grow as new options are added, which means that when code outside the library tries to use a feature, it first has to test for it, and have code to handle it not being available. The indexopts approach proposed here instead makes it clear at compile time and at dynamic link time that there is an explicit dependency on that feature, which allows automated tools to keep track of what's needed and keeps the actual code simple. My proposal adds the notmuch_indexopts_t as an opaque struct, so that we can extend the list of options without causing ABI breakage. The cost of this proposal appears to be that the "boilerplate" API increases a little bit, with a generic constructor and destructor function for the indexopts struct. More patches will follow that make use of this indexopts approach.
2017-08-18 01:14:26 +02:00
$(dir)/indexopts.c \
xutil.c: remove duplicate copies, create new library libutil.a to contain xutil. We keep the lib/xutil.c version. As a consequence, also factor out _internal_error and associated macros. It might be overkill to make a new file error_util.c for this, but _internal_error does not really belong in database.cc.
2011-10-23 17:05:13 +02:00
$(dir)/tags.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: add date range query support Add a custom value range processor to enable date and time searches of the form date:since..until, where "since" and "until" are expressions understood by the previously added date/time parser, to restrict the results to messages within a particular time range (based on the Date: header). If "since" or "until" describes date/time at an accuracy of days or less, the values are rounded according to the accuracy, towards past for "since" and towards future for "until". For example, date:november..yesterday would match from the beginning of November until the end of yesterday. Expressions such as date:today..today means since the beginning of today until the end of today. Open-ended ranges are supported (since Xapian 1.2.1), i.e. you can specify date:..until or date:since.. to not limit the start or end date, respectively. CAVEATS: Xapian does not support spaces in range expressions. You can replace the spaces with '_', or (in most cases) '-', or (in some cases) leave the spaces out altogether. Entering date:expr without ".." (for example date:yesterday) will not work as you might expect. You can achieve the expected result by duplicating the expr both sides of ".." (for example date:yesterday..yesterday). Open-ended ranges won't work with pre-1.2.1 Xapian, but they don't produce an error either. Signed-off-by: Jani Nikula <jani@nikula.org>
2012-10-30 21:32:37 +01:00
$(dir)/parse-time-vrp.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 \
lib: isolate n_d_add_message and helper functions into own file 'database.cc' is becoming a monster, and it's hard to follow what the various static functions are used for. It turns out that about 1/3 of this file notmuch_database_add_message and helper functions not used by any other function. This commit isolates this code into it's own file. Some side effects of this refactoring: - find_doc_ids becomes the non-static (but still private) _notmuch_database_find_doc_ids - a few instances of 'string' have 'std::' prepended, avoiding the need for 'using namespace std;' in the new file.
2017-06-04 14:32:24 +02:00
$(dir)/add-message.cc \
lib: basic message-property API Initially, support get, set and removal of single key/value pair, as well as removing all properties.
2016-06-13 03:05:50 +02:00
$(dir)/message-property.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)/query.cc \
lib: add support for named queries This relies on the optional presense of xapian field processors, and the library config API.
2016-03-22 11:54:54 +01:00
$(dir)/query-fp.cc \
lib: provide config API This is a thin wrapper around the Xapian metadata API. The job of this layer is to keep the config key value pairs from colliding with other metadata by transparently prefixing the keys, along with the usual glue to provide a C interface. The split of _get_config into two functions is to allow returning of the return value with different memory ownership semantics.
2016-03-22 11:54:47 +01:00
$(dir)/config.cc \
lib: regexp matching in 'subject' and 'from' the idea is that you can run % notmuch search subject:/<your-favourite-regexp>/ % notmuch search from:/<your-favourite-regexp>/ or % notmuch search subject:"your usual phrase search" % notmuch search from:"usual phrase search" This feature is only available with recent Xapian, specifically support for field processors is needed. It should work with bindings, since it extends the query parser. This is easy to extend for other value slots, but currently the only value slots are date, message_id, from, subject, and last_mod. Date is already searchable; message_id is left for a followup commit. This was originally written by Austin Clements, and ported to Xapian field processors (from Austin's custom query parser) by yours truly.
2017-02-27 03:34:20 +01:00
$(dir)/regexp-fields.cc \
lib: add thread subqueries. This change allows queries of the form thread:{from:me} and thread:{from:jian} and not thread:{from:dave} This is still somewhat brute-force, but it's a big improvement over both the shell script solution and the previous proposal [1], because it does not build the whole thread structure just generate a query. A further potential optimization is to replace the calls to notmuch with more specialized Xapian code; in particular it's not likely that reading all of the message metadata is a win here. [1]: id:20170820213240.20526-1-david@tethera.net
2017-12-26 02:03:05 +01:00
$(dir)/thread.cc \
$(dir)/thread-fp.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
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 $@ $^
build: switch to hiding libnotmuch symbols by default The dynamic generation of the linker version script for libnotmuch exports has grown rather complicated. Reverse the visibility control by hiding symbols by default using -fvisibility=hidden, and explicitly exporting symbols in notmuch.h using #pragma GCC visibility. (We could also use __attribute__ ((visibility ("default"))) for each exported function, but the pragma is more convenient.) The above is not quite enough alone, as it would "leak" a number of weak symbols from Xapian and C++ standard library. Combine it with a small static version script that filters out everything except the notmuch_* symbols that we explicitly exposed, and the C++ RTTI typeinfo symbols for exception handling. Finally, as the symbol hiding test can no longer look at the generated symbol table, switch the test to parse the functions from notmuch.h.
2017-05-10 21:42:11 +02:00
$(dir)/$(LIBNAME): $(libnotmuch_modules) util/libnotmuch_util.a parse-time-string/libparse-time-string.a
rename libutil.a to libnotmuch_util.a Apparently some systems (MacOS?) have a system library called libutil and the name conflict causes problems. Since this library is quite notmuch specific, rename it to something less generic.
2017-03-14 12:10:07 +01:00
$(call quiet,CXX $(CXXFLAGS)) $(libnotmuch_modules) $(FINAL_LIBNOTMUCH_LDFLAGS) $(LIBRARY_LINK_FLAG) -o $@ util/libnotmuch_util.a parse-time-string/libparse-time-string.a
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
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)
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: fix typos in CLEAN setting, add file - c0961e6 introduced a missing slash between $(dir)$(LIBNAME) and missing $(dir) in front of libnotmuch.a - cdf1c70a created a file $(dir)/notmuch.h.gch and neglected to add it to CLEAN
2011-06-25 14:45:58 +02:00
CLEAN += $(libnotmuch_modules) $(dir)/$(SONAME) $(dir)/$(LINKER_NAME)
build: switch to hiding libnotmuch symbols by default The dynamic generation of the linker version script for libnotmuch exports has grown rather complicated. Reverse the visibility control by hiding symbols by default using -fvisibility=hidden, and explicitly exporting symbols in notmuch.h using #pragma GCC visibility. (We could also use __attribute__ ((visibility ("default"))) for each exported function, but the pragma is more convenient.) The above is not quite enough alone, as it would "leak" a number of weak symbols from Xapian and C++ standard library. Combine it with a small static version script that filters out everything except the notmuch_* symbols that we explicitly exposed, and the C++ RTTI typeinfo symbols for exception handling. Finally, as the symbol hiding test can no longer look at the generated symbol table, switch the test to parse the functions from notmuch.h.
2017-05-10 21:42:11 +02:00
CLEAN += $(dir)/$(LIBNAME) $(dir)/libnotmuch.a
libnotmuch: fix typos in CLEAN setting, add file - c0961e6 introduced a missing slash between $(dir)$(LIBNAME) and missing $(dir) in front of libnotmuch.a - cdf1c70a created a file $(dir)/notmuch.h.gch and neglected to add it to CLEAN
2011-06-25 14:45:58 +02:00
CLEAN += $(dir)/notmuch.h.gch
Reference in a new issue Copy permalink