Re: problem with "make index"

Am 17.07.22 um 00:27 schrieb 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 issue was not that it was not possible to compile WASI with LLVM 14, but
instead that users who for whatever legitimate reason wanted to build their
ports with the ports version of LLVM 14 could not build the INDEX file.

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

Setting LLVM_DEFAULT=14 may well be reasonable and required for some use cases,
and this should not result in a broken "make index".

I do therefore consider "those who are not knowing what they are doing" as
disrespectful and inappropriate!

>> 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.
>>
> Those are the related reviews, and all must be congruent.

Yes, and therefore I'd have recorded this interdependence in the reviews,
if they had been created by me.

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

The revert has been committed with as 973550dd663c.

Regards, STefan