portgroups cargo, cargo-fetch fail to build new port topgrade

[lhaeger (Lothar Haeger)]

I'm trying to submit a new port "topgrade" (​https://github.com/macports/macports-ports/pull/6484) using the cargo portgroup, but building fails and I do find the reason (log from CI attached).

I get the exact same error when trying to build locally, but only when running

sudo port install -vst topgrade

The software builds just fine, though, when I cd into the work directory and run the build cmd from the log manually as:

cd /opt/local/var/macports/build/_Users_lhaeger_Documents_Source_macports-ports_sysutils_topgrade/topgrade/work/r-darwish-topgrade-aeb91c9
sudo cargo clean
sudo cargo build --release --frozen -v -j4"

I therefore suspect the cargo/cargo_fetch portgroups to cause the issue somehow.

Would be cool if someone knowing those portgroups could look into this and point me into the right direction.

[lhaeger (Lothar Haeger)]

Build fails running "sudo port install -vst"

[lhaeger (Lothar Haeger)]

Build succeeds running "sudo cargo build --release --frozen -v -j4"

[ryandesign (Ryan Carsten Schmidt)]

Well the first error in the fail log is:

cargo:warning=In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/ncurses.h:141:
cargo:warning=/opt/local/include/unctrl.h:61:63: error: unknown type name 'SCREEN'

This shows you're using macOS ncurses.h but MacPorts unctrl.h. These are both headers that belong to the ncurses software but macOS and MacPorts provide different versions of that software so the headers are apparently not interchangeable. Either use all macOS ncurses headers and libraries or (ideally) use all MacPorts ncurses headers and libraries.

[lhaeger (Lothar Haeger)]

Replying to ryandesign:

This shows you're using macOS ncurses.h but MacPorts unctrl.h. These are both headers that belong to the ncurses software but macOS and MacPorts provide different versions of that software so the headers are apparently not interchangeable. Either use all macOS ncurses headers and libraries or (ideally) use all MacPorts ncurses headers and libraries.

Thanks a lot for the hint, so I'll have to try to figure out how to force one or the other version. Any more hints on that, maybe?

[kencu (Ken)]

you probably cannot fix this by configuring your build. If it's like the other examples we've seen of this, it has to do with clang using modules and mixing this up. We could disable screen extras in our ncurses build, but that's felt to be imperfect. We could edit the unctrl.h header and tweak in a fix, but that's inelegant. We bumped this upstream to Apple a few weeks back.

Until that gets sorted out someday, you're DOA on MacPorts ( homebrew apparently doesn't see this error, at least it is only reported on MacPorts and never there, possibly as they install headers into /usr/local and that's on the default search path.)

So, after you dig a bit, if it is modules causing the error, you won't be able to use MacPorts until it gets resolved. You can edit a quick hack into your own version of /opt/local/include/unctrl.h to fix it for yourself ( that's what I did ) pending either us tweaking ours in our ncurses build formally (unlikely) or App fixing modules (will happen, no idea when). Or perhaps the MacPorts decision to leave this will turn if it affects enough people, hard to say...

[kencu (Ken)]

see #59992

[lhaeger (Lothar Haeger)]

Modified the port to use the pre-built binary from upstream as a workaround until this issue is solved.

@kencu: if you see a fix being implemented, would you mind bumping this issue, just in case I miss it, please?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Adding

compiler.cpath

seems to allow your port to build.

See ​https://trac.macports.org/ticket/59992#comment:20 for an explanation.

[kencu (Ken)]

if you clear compiler.cpath, are the headers in /opt/local being used at all? If not, then we should clear the libs in /opt/local too, as you wouldn't want those to be used. . (which, in effect, is not using MacPorts at all, I guess).

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to kencu:

if you clear compiler.cpath, are the headers in /opt/local being used at all? If not, then we should clear the libs in /opt/local too, as you wouldn't want those to be used. . (which, in effect, is not using MacPorts at all, I guess).

Fair point.
For the sake of completeness, it might be better to add

compiler.cpath
compiler.library_path

Since this port has no non-build MacPorts dependencies, I do not think this is a problem.

[kencu (Ken)]

yes, disabling all macports includes and libraries might work for this one port. or perhaps another at some point.

However, the others mentioned in the other ticket, like clang-devel, not so lucky. they need macports libraries.

so far, the only example of an error when mixing headers is ncurses. If we tweak our unctrl.h, that buys us time for upstream to roll out a proper clang fix eventually.

So that is why I am advocating for that rather than disabling macports libraries and includes.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

We have found a workaround for this particular port.
We have an ​open ticket to track the fundamental issue.
Any solution we settle on can easily be incorporated into topgrade without even a rebuild.

I will therefore merge ​PR 6484, close this ticket, and continue the discussion on the parent ticket.