notmuch: build conflict declared against itself, forcing users to deactivate before updating

[mascguy (Christopher Nielsen)]

When attempting to update this port today, it failed with the following:

--->  Configuring notmuch
Error: notmuch cannot be built while another version of notmuch is active.
Error: Please forcibly deactivate the existing copy of notmuch, e.g. by running:
Error: 
Error:     sudo port -f deactivate notmuch
Error: 
Error: Then try again.
Error: Failed to configure notmuch: notmuch is active

Reviewing the portfile, the following is declared for conflicts_build:

conflicts_build ${name} xcbuild

Since this port declares a build conflict with itself, users have to deactivate it - forcibly, if a dependent like astroid is also installed - simply to update it.

While the conflict is legitimate, we should try to fix if possible.

[rseichter (Ralph Seichter)]

According to the Git commit history, conflicts_build ${name} was added by Ryan Schmidt for notmuch 0.14 in 2012, and Sean Farley changed it to conflicts_build ${name} xcbuild for notmuch 0.24 in 2017. I can only assume what their respective reasons were; the notmuch versions are definitely very outdated. I made my first change to the Portfile in 2019 and have left many things as they were, simply because I did not want to meddle with what I did not understand well enough. If you are certain that getting rid of the conflicts_build references does not break the build, by all means remove any cruft you find.

[mascguy (Christopher Nielsen)]

No worries, just trying to identify/fix things which might impact our users. And thank you for taking ownership of this port, much appreciated!

Ryan, any thoughts, re: the reasoning behind the build conflict declarations?

[mascguy (Christopher Nielsen)]

Based on local testing, there is an issue when an older version is active: Compilation references header ${prefix}/include/notmuch.h.

We could fix this either by 1) forcibly deactivating the previous version, if installed/active; or 2) updating the build to prioritize the port's header files first. The latter might be preferable, if it's easy.

[mascguy (Christopher Nielsen)]

I'll add this to my backlog.

Worst-case, we punt on it, and keep it as-is: While a minor inconvenience, it's not a show-stopper by any means. Nonetheless, if there's a relatively simple (and reliable) fix, it's worth spending a few minutes to investigate.

[ryandesign (Ryan Schmidt)]

As you can see from my commit message this was done to "prevent build conflict when previous version of notmuch is active".

This type of build conflict usually happens when the build system has its -I flags in the wrong order. -I/opt/local/include is probably appearing in the compile lines before the -I flags that reference the build directories, and it must be the other way around.

We can see this is indeed the case by looking at a recent ​build log: the first compile line is:

/usr/bin/clang -c -DNOTMUCH_VERSION=0.32.2 -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch arm64 -Wall -Wextra -Wwrite-strings -Wmissing-declarations  -I./util -I./compat -I./lib -fPIC -fvisibility=hidden -I./parse-time-string -I. -D_REENTRANT -I/opt/local/include/gmime-3.0 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include   -DHAVE_VALGRIND=0  -DHAVE_GETLINE=1 -DWITH_EMACS=0 -DHAVE_CANONICALIZE_FILE_NAME=0 -DHAVE_STRCASESTR=1 -DHAVE_STRSEP=1 -DHAVE_TIMEGM=1 -DHAVE_D_TYPE=1 -DSTD_GETPWUID=1 -DSTD_ASCTIME=1 -DSILENCE_XAPIAN_DEPRECATION_WARNINGS -DHAVE_XAPIAN_DB_RETRY_LOCK=1 command-line-arguments.c -o command-line-arguments.o -MD -MP -MF .deps/command-line-arguments.d

We see -I/opt/local/include preceding -I./util -I./compat -I./lib and -I./parse-time-string -I..

If you want to work on fixing it, that's what to work on. It's usually an upstream issue, so your fix should be reported to the project's developers.

Instead of fixing that, it can often be worked around by using:

configure.cppflags-replace -I${prefix}/include -isystem${prefix}/include

All paths specified with -isystem will be searched after all paths specified with -I.

[Christopher Nielsen <mascguy@…>]

In c69c26cfc573075d1260e30ba2cd9c42033b8ab6/macports-ports (master):

notmuch: eliminate build conflict with previous version during upgrade
Fixes: #63274

[mascguy (Christopher Nielsen)]

Reopening, due to new link-time error: issue:63665

[Christopher Nielsen <mascguy@…>]

In 3dc1da300b10f785071132b1aff48a28e01b7638/macports-ports (master):

notmuch: revert previous fix for build conflict
Fixes: #63665
See: #63274

[ryandesign (Ryan Schmidt)]

Fix coming shortly.

I reported the problem to the developers' mailing list but it has not shown up in the web archive yet so I can't share the URL here yet.

[ryandesign (Ryan Schmidt)]

In 73d5a1003d3be2bc6a8aa364669a56a1a5511bc0/macports-ports (master):

notmuch: Fix self build conflict

Closes: #63274
Closes: #63665