llvm dev - Aug 2020 - Clang is a resource hog, the installers for Windows miss quite some files, and are defect!

"Michael Kruse" <llvmdev at meinersbur.de> wrote:
> I think David is not referring to the capitalization of file names, but to
> "DUPLICATE", "WASTING", "NOT AMUSED",
"BOGUS" etc.
I EMPHASIZE in the only way possible with plain text.
> It should be possible to report problems in a professional manner.
It should also be possible to handle problem reports in a professional
manner!
> Please remember that the project is made available by volunteers
> for free. We also have a dedicated bug tracker: bugs.llvm.org.
You are free to enter the bugs I pointed out there.
I don't use LLVM, so don't expect me to jump throught loops to report
obvious bugs.
> Am Do., 20. Aug. 2020 um 13:49 Uhr schrieb Stefan Kanthak via llvm-dev
<llvm-dev at lists.llvm.org>:
>
>> BUGS #1 & #2:
>> ~~~~~~~~~~~~~
>>
>
> On UNIX systems, these are symlinks.
UNIX and Windows are quite different.
> There are multiple potential equivalents to symlinks on Windows systems,
> the one matching UNIX systems the closest is relatively new and requires
> either Administrator rights or developer mode turned on.
Hardlinks don't. And they are available on both systems.
> Typically tools ported from a UNIX environment to Windows just copy the
> file instead symlinking to avoid dealing with issues such as when the
> installing on a non-NTFS file system (FAT, network drive, etc),
Do you really want to tell that the installer LLVM uses on Windows was
ported from UNIX?
REALITY CHECK, please!
The default installation goes into %ProgramFiles%\LLVM, which is located
on NTFS.
> so does LLVM (
https://github.com/llvm/llvm-project/blob/master/llvm/cmake/modules/LLVMInstallSymlink.cmake
).
> Since mass storage is cheap, there isn't a lot of motivation to save to
> invest time to save some space. However, you are free to invest that time
> yourself and submit patches.
I'm even free not to use LLVM at all, but nevertheless see and report its
bugs and deficiencies here: be professional and fix them
>> BUG #5:
>> ~~~~~~~
>>
>> Poor souls who want to install the 64-bit package after/aside the
>> 32-bit package (or vice versa) are greeted with the following BOGUS
>> message from the installers:
>>  ______________________________________________________
>> | Installation von LLVM
>> |¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
>> |  ^
>> | /!\ LLVM is already installed.
>> | ¯¯¯
>> |     Do you want to install the old version before
>> |     installing the new one?
>> |
>> |     [ Ja ] [ Nein ] [ Abbrechen ]
>> |
>>  ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
>> Also note the denglish kauderwelsch: the title bar and the buttons
>> are localized, but the message text isn't.
>>
>>
> The button labels and message box title are provided by the Operating
> System / Nullsoft Install System.
To use this obviously defective "install system" is then a rather poor
choice.
> LLVM itself does not do any localization itself.
> I'd be more concerned that if offers to "install the old
version"
> (rather than uninstall it).
This seems to be a typo.
I'd rather be concerned about the OLD version here, which might be
ANY other version, older, newer, or the same, but just for the other
processor architecture of the target OS!

Do you consider such misleading messages appropriate for a product
developed by professionals?
> My guess this warning is a functionality provided by the Nullsoft Install
> System that assumes that software only needs to be installed once on the
> system. I wouldn't call it bogus, you may indeed not want to keep an
older
> version installed at the same time.
Most obviously this "install system" was the wrong choice for LLVM.

BUG #8:
~~~~~~~

The defective installer creates a shortcut "Uninstall LLVM" in the
start menu, violating the MINIMUM requirements of the now 25 year old
"Designed for Windows guidelines".

JFTR: Windows ships with two builtin installers (SetupAPI and Windows
      Installer), there's no need to use a defective 3rd party product
      at all.

Stefan

Stefan Kanthak via llvm-dev <llvm-dev at lists.llvm.org> writes:
> "Michael Kruse" <llvmdev at meinersbur.de> wrote:
>
>> I think David is not referring to the capitalization of file names, but
to
>> "DUPLICATE", "WASTING", "NOT AMUSED",
"BOGUS" etc.
>
> I EMPHASIZE in the only way possible with plain text.
There are *many* ways to _emphasize_ text without shouting.
                                          ~~~~~~~
>> It should be possible to report problems in a professional manner.
>
> It should also be possible to handle problem reports in a professional
> manner!
>From everything I have read, both Michael and David were very
professional in their responses.  You're just not going to get a lot of
sympathy when you approach things in an adversarial manner.  It turns
people off.
>> Please remember that the project is made available by volunteers
>> for free. We also have a dedicated bug tracker: bugs.llvm.org.
>
> You are free to enter the bugs I pointed out there.
That's not the way it works in a project where people freely volunteer
their time.  If someone else feels this is a serious problem, they may
very well file a proper bug.  But if not, this report isn't going
anywhere unless you file a bug and even then there's no guarantee people
will have the time to work on it.
> I don't use LLVM, so don't expect me to jump throught loops to
report
> obvious bugs.
I guess I don't understand your concern then.  If you don't use LLVM,
why are you installing it and why do you care about its size?
>> On UNIX systems, these are symlinks.
>
> UNIX and Windows are quite different.
True.
>> There are multiple potential equivalents to symlinks on Windows
systems,
>> the one matching UNIX systems the closest is relatively new and
requires
>> either Administrator rights or developer mode turned on.
>
> Hardlinks don't. And they are available on both systems.
They aren't available on FAT32 filesystems though.
>> Typically tools ported from a UNIX environment to Windows just copy the
>> file instead symlinking to avoid dealing with issues such as when the
>> installing on a non-NTFS file system (FAT, network drive, etc),
>
> Do you really want to tell that the installer LLVM uses on Windows was
> ported from UNIX?  REALITY CHECK, please!  The default installation
> goes into %ProgramFiles%\LLVM, which is located on NTFS.
I am not familiar with the Windows installer.  There's no installer as
such for Unix-like systems.

There probably is some way to detect the filesystem type of the install
directory and create links.  It's a matter of someone feeling it's
important enough to do.  Shouting about it won't make it happen faster.
>> Since mass storage is cheap, there isn't a lot of motivation to
save to
>> invest time to save some space. However, you are free to invest that
time
>> yourself and submit patches.
>
> I'm even free not to use LLVM at all, but nevertheless see and report
its
> bugs and deficiencies here: be professional and fix them
Professionals don't make demands of others.  You've been pointed to the
correct process for reporting bugs.  If you aren't able or willing to do
that there's not a lot the community is going to do for you, especially
if you keep disparaging its members.

                -David

"David Greene" <dag at hpe.com> wrote:
> Stefan Kanthak via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 
>> "Michael Kruse" <llvmdev at meinersbur.de> wrote:
>>
>>> I think David is not referring to the capitalization of file names,
but to
>>> "DUPLICATE", "WASTING", "NOT AMUSED",
"BOGUS" etc.
>>
>> I EMPHASIZE in the only way possible with plain text.
> 
> There are *many* ways to _emphasize_ text without shouting.
>                                          ~~~~~~~
How ugly; I prefer UPPER CASE!
>>> It should be possible to report problems in a professional manner.
>>
>> It should also be possible to handle problem reports in a professional
>> manner!
> 
> From everything I have read, both Michael and David were very
> professional in their responses.
Both had nothing better to do than to mock about my way of emphasizing!
That's childish and completely unprofessional.

[...]
>> I don't use LLVM, so don't expect me to jump throught loops to
report
>> obvious bugs.
> 
> I guess I don't understand your concern then.  If you don't use
LLVM,
> why are you installing it and why do you care about its size?
Who said I installed it?
Some poor soul installed it because he got the advice to use LLVM/clang
because "it is better than MinGW or MSVC/Visual Studio".
After that he wondered why he can compile for i386, but can't link the
compiled objects ... so he asked me.
I VOLUNTARILY took my time to see what was installed, and how it was
installed: I noticed the wasted 0.5GB and the missing clang-rt.*-i386.lib
He was DEFINITELY not amused, and called the $*%@ who built this crap
names.

I but dared to copy clang-rt.builtins-{i386,x86-64}.lib and verified the
still POOR performance, especially for 64-bit division on i386 and 128-bit
division on AMD64.

JFTR: __udivmoddi4 and __udivmodti4 are even slower than in LLVM 7.0.0!

[...]
>>> There are multiple potential equivalents to symlinks on Windows
systems,
>>> the one matching UNIX systems the closest is relatively new and
requires
>>> either Administrator rights or developer mode turned on.
>>
>> Hardlinks don't. And they are available on both systems.
> 
> They aren't available on FAT32 filesystems though.
The DEFAULT installation directory is on NTFS.

JFTR: since Windows Vista, introduced 14 years ago, the boot partition
      must be NTFS.

Stefan