Re: problem with "make index"

Am 16.07.22 um 03:12 schrieb Charlie Li:
> I need to clear some stuff here. There was a phab review brewing for some time 
> https://reviews.freebsd.org/D35288

Hi,

sorry, I have not been aware of the review. It has been opened on 2022-05-22,
and I see that it has been worked on in the nearly 8 weeks since then, with
the last update of the proposed patch ten days ago.

> Stefan Esser wrote:
>> I have just committed a port for LLVM 14. It is build tested, but I did
>> not have time to perform any run tests.
>>
> First mistake. The entire WASI toolchain has to be updated, since this is LLVM 
> and no API/ABI compatibility between major versions and all. See the phab 
> chain, where one item actually had to be reverted to a previous upstream revision.

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.

>> I have copied over the Makefile of the wasi-compile-rt13 port and have
>> only changed the DISTVERSION to 14.0.6 and regenerated the distinfo file.
>>
>>>     B) will setting LLVM_DEFAULT to 13 (there _is_ a wasi-compiler-rt13)
>>> fix things?
>>
>> Yes, if you do not need LLVM 14 for some reason, then staying at 13
>> is the easy way to resolve such issues, until version 14 is fully
>> supported in the ports tree.
>>
> Staying at 13 or another LLVM version where the entire chain's version matches 
> is required unless you are okay with unexpected or unexplainable failures.

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?

>> Please let me know if you find that the wasi-compile-rt14 port does not
>> work correctly.
>>
>> I have preserved the MAINTAINER of wasi-compile-rt13 in this port, but
>> if there are issues,  I'd feel responsible to fix them before handing
>> the responsibility for further updates over to greg ... ;-)
>>
> I will go further:
> 
> This was not to be committed at all right now, despite appearances. And I say 
> this as one who is still dogfooding the entire WASI-LLVM 14 chain, with 
> www/firefox as the prime consumer, with LTO enabled. Those interested in 
> helping dogfood, identify failure modes, et al with LLVM_DEFAULT=14 can grab 
> the entire diff chain off phab and apply it to your own tree or overlay.

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?

I see that D35286 to D35389 cover this whole topic, and that there still are
unresolved run-time issues that prevent them from actually being used.

BTW: I see that wasi-libc and wasi-libc++ do not contain the LLVM version
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
have some mention of LLVM_DEFAULT in the package base name?

> 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?

But there still is the issue of the missing wasi-compile-rt14 breaking
"make index" with LLVM_DEFAULT=14 and some (working or not working) port
needs to exist at that origin to allow this changed default (Which may be
required to test other ports with LLVM 14).

Please try to find a solution that does not prevent "make index" with a
non-default LLVM_VERSION - perhaps a commit of a Makefile skeleton with
just the minimum set of variables and IGNORE set as suggested above?

Feel free to revert the commit if you think it would be causing issues for
you (e.g. bug reports for a known unfinished port),  but I'd really prefer
the port to exist but be ignored.

Regards, STefan