Re: problem with "make index"

[Charlie Li]

Stefan Esser wrote:

The reason that I have committed the port at this time was that "make index"

is broken with LLVM_DEFAULT set to 14. I have considered this a fix of the
port system, but forgot to mention that detail in the commit log.

Not when the other components of the WASI toolchain are also required to actually function. The default LLVM_DEFAULT is still not 14, so those who change the settings on their setups have to bear at least some responsibility for any fallout (despite best efforts on maintainers' to qualify other option/setting combinations).> The problem with a missing wasi-compile-rt14 port is that it breaks "make

index" even for users that are not interested in WASI at all ...

Maybe, a port should have been committed marked

     IGNORE= Not ready, see https://reviews.freebsd.org/D35288

in order to not break "make index" with the non-default LLVM_DEFAULT?

This has now been remedied in commit 6b2cf7d799d86f3e577d45a11b1010305e79351f ostensibly to hinder those who don't know what they are doing from this, unless interested in actually figuring out how to make it all work (like myself). So unless there existed use cases or consumers outside or not appropriate for the ports tree, not committing this port was the only correct choice.

There is no mention of related revisions in https://reviews.freebsd.org/D35288, maybe you could connect this review to others that are required for WASI with

LLVM 14?


unresolved run-time issues that prevent them from actually being used.

I see that D35286 to D35389 cover this whole topic, and that there still are

Those are the related reviews, and all must be congruent.

BTW: I see that wasi-libc and wasi-libc++ do not contain the LLVM version

have some mention of LLVM_DEFAULT in the package base name?

in their ${PKGBASE} values. I'd have expected that only wasi-libc built with LLVM 14 could be used in wasi-compile-rt14 and thus that it would be good to

wasi-libc doesn't do releases, just commits/snapshots. Any quick look at the source reveals that they effectively support only one LLVM version at a time, and since earlier this year that has been LLVM 14. The current port has not been updated so as to ensure LLVM 13 compatibility.

wasi-libcxx on the other hand could switch to version suffixes, however, since it uses the same LLVM sources.

But that doesn't address an even bigger issue that's still being figured out: how to make this whole situation, LTO or not, less fragile to deal with.

I see - do you want me to revert this commit?

Please do.

--
Charlie Li
…nope, still don't have an exit line.

OpenPGP_signature
Description: OpenPGP digital signature