Opened 2 years ago

Closed 22 months ago

#63274 closed defect (fixed)

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

Reported by: mascguy (Christopher Nielsen) Owned by: mascguy (Christopher Nielsen)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: rseichter (Ralph Seichter), ryandesign (Ryan Schmidt)
Port: notmuch

Description (last modified by 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:     sudo port -f deactivate notmuch
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.

Change History (11)

comment:1 Changed 2 years ago by 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.

Version 0, edited 2 years ago by rseichter (Ralph Seichter) (next)

comment:2 Changed 2 years ago by mascguy (Christopher Nielsen)

Cc: ryandesign added

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?

comment:3 Changed 2 years ago by 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.

comment:4 Changed 2 years ago by mascguy (Christopher Nielsen)

Cc: rseichter added; ryandesign removed
Owner: changed from rseichter to mascguy

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.

comment:5 Changed 2 years ago by mascguy (Christopher Nielsen)

Description: modified (diff)

comment:6 Changed 2 years ago by 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.

comment:7 Changed 2 years ago by Christopher Nielsen <mascguy@…>

Resolution: fixed
Status: assignedclosed

In c69c26cfc573075d1260e30ba2cd9c42033b8ab6/macports-ports (master):

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

comment:8 Changed 2 years ago by mascguy (Christopher Nielsen)

Resolution: fixed
Status: closedreopened

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

comment:9 Changed 2 years ago by Christopher Nielsen <mascguy@…>

In 3dc1da300b10f785071132b1aff48a28e01b7638/macports-ports (master):

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

comment:10 Changed 22 months ago by ryandesign (Ryan Schmidt)

Cc: ryandesign added

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.

comment:11 Changed 22 months ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: reopenedclosed

In 73d5a1003d3be2bc6a8aa364669a56a1a5511bc0/macports-ports (master):

notmuch: Fix self build conflict

Closes: #63274
Closes: #63665

Note: See TracTickets for help on using tickets.