When pkg-config does not find configure, a compat version of the
zlib.pc is created. In creation of that configure attempted to
read values of $zlib_cflags and $zlib_ldflags. In the usual case
those were undefined, and with `set -a` now in the beginning of
configure, configure broke.
Even if $zlib_cflags and $zlib_ldflags had values which were used
to create zlib.pc, the values were overwritten (with static content)
a few lines later in next pkg-config --cflags and --libs run. These
values would not be different and probably useless -- the following
boild would probably fail.
But instead of using those, CPATH and LIBRARY_PATH environment
variables can be used successfully (both while configuring and
building).
This is primarily intended for use in the test suite (since notmuch
builds fine without gnupg installed). Thus we only write the variable
to sh.config.
Removing the removal of byteorder configure test files was overlooked
in commit 5a957c3f33 ("build & util: drop byte order configure check
and endian util header"). Finish the job.
With the removal of the embedded libsha1, we lost the first and last
user of the platform byte order checks. Remove them from configure,
and remove the endian util header.
Since the sed expansion line which did $prefix expansion for
libdir_expanded was changed from the legacy `...` format to the
new $(...) expression, the subtle backslash expansion change went
unnoticed -- \\$ which used to escape '$' now escapes '\' and the
following '$prefix' was attempted to expand as a variable. So
changing \\$ to \$ fixes this.
Also, replaced echo with printf %s -- echo does expansions of its own.
While at it, the following 2 inconsistencies were fixed:
1) the /g flag was removed from first expression; second didn't have it
2) first expression did not end with /, so "dropped" it from second
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
There is really no need to have a separate install target for the
desktop file. Just install the desktop file with emacs, with a
configure option to opt out.
It seems that no-one tried to compile without Xapian compact support
since March of 2015, since that's when I introduced a syntax error in
that branch of the ifdef.
Given the choice of maintaining this underused branch of code, or
bumping the Xapian dependency to a version from 2011, it seems
reasonable to do the latter.
Since commit
124a67e96e: configure: add set -u
all variables must be set before their expansion are attempted. These
2 variables: "platform" and "linker_resolves_library_dependencies" were
not given value in the final 'else' branch when platform check failed
due to unrecognized kernel name (output of `uname`). Now those two are
given reasonable non-empty values.
Add option to explicitly disable API man page build even if doxygen
binary is available. --without-docs also implies not building API
manpage.
This change intended to add more distinctness into build system and
allow user not to build unwanted man pages.
Xapian 1.3 has introduced the DB_RETRY_LOCK flag (Xapian bug
275). Detect it in configure and optionally use it. With this flag
commands that need the write lock will wait for their turn instead of
aborting when it's not immediately available.
Amended by db: allow disabling in configure
Many of the external links found in the notmuch source can be resolved
using https instead of http. This changeset addresses as many as i
could find, without touching the e-mail corpus or expected outputs
found in tests.
By combining the common parts of CONFIGURE_CFLAGS and CONFIGURE_CXXFLAGS
to a separate make variable and using that as part of their
definitions makes setting of these easier, DRYer and less error prone
(especially as we cannot check potential typing errors there).
In case of any unset variable, make ./configure exit with nonzero value;
an attempt to expand an unset variable is a bug in the script
(usually a spelling mistake) and those should not pass through
unnoticed.
This is mainly for the test suite. We already expect the tests to be
run in the same environment as configure was run, at least to get the
name of the python interpreter. So we are not really imposing a new
restriction.
Checking the existence of timegm() function and setting
configure internal variable ${have_timegm} was done, but
actually defining HAVE_TIMEGM in build was not done --
meaning that compat timegm() was always part of final
notmuch binaries.
This does not play well with --prefix. As Tomi notes in
id:m2k2p2rwth.fsf@guru.guru-group.fi, people still have the option of e.g.
% ./configure ---emacslispdir=`pkg-config emacs --variable sitepkglispdir`
It's becoming a maintenance burden to do anything things with the
crypto glue code twice, once for 2.4 and once for 2.6. I don't have
any 2.4 version available to test on my development machine anymore,
so the 2.4 specific code paths are likely not very well tested.
- Make lib/notmuch.h the canonical location for the library versioning
information.
- Since the release-check should never fail now, remove it to reduce
complexity.
- Make the version numbers in notmuch.h consistent with the (now
deleted) ones in lib/Makefile.local
The configure script chooses "python" if both python and python{2,3}
exist exists, so this could change the version of python used to run
the test suite.
The checking for ${NOTMUCH_PYTHON} in the test suite is arguably
over-engineering, since the configure step will fail if it can't find
it.
Previously documentation was build automatically if sphinx/doxygen
executable were found. The switch is used to unconditionally disable
sphinx/doxygen detection and therefor, building of documentation
(including man pages).
Because ruby generates a Makefile, we have to use recursive make.
Because mkmf.rb hardcodes the name Makefile, put our Makefile{.local}
in the parent directory.
Passing in environment variables incompatible with the compiler may
cause other parts of the configure script to fail in hard to
understand ways, so we abort early.
When the shell builtin `command -v` operates normally, it either
prints the path of the arg given to it and returns zero -- or it
returns nonzero and prints nothing.
In abnormal situations something might be printed to stderr and
in that case we want to know about it; therefore the used
command -v stderr redirections to /dev/null have been removed.
The `hash` (builtin) command in ksh returns zero even the arg
given to is is not found in path. For that and for consistency
the one appearance of it has been converted to `command -v`.
Currently we hardcode "python" in several places. This makes things
hard for people who have only commands called python3 and/or
python2. We also add the name to sh.config to eventually replace the
current workaround in the test suite.
There was theorical possibility that writing the config files could
have skipped (by interruption) after the instructions how to make
notmuch was printed out.
