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.