Opened 3 years ago
Closed 3 years 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 Carsten 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: 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.
Change History (11)
comment:1 Changed 3 years ago by rseichter (Ralph Seichter)
comment:2 Changed 3 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 3 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 3 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 3 years ago by mascguy (Christopher Nielsen)
Description: | modified (diff) |
---|
comment:6 Changed 3 years ago by ryandesign (Ryan Carsten 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 3 years ago by Christopher Nielsen <mascguy@…>
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:8 Changed 3 years ago by mascguy (Christopher Nielsen)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Reopening, due to new link-time error: issue:63665
comment:9 Changed 3 years ago by Christopher Nielsen <mascguy@…>
comment:10 Changed 3 years ago by ryandesign (Ryan Carsten 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 3 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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 toconflicts_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 theconflicts_build
references does not break the build, by all means remove any cruft you find.