[cfe-dev] Cannot CMake self-hosted clang on Windows for lack of libxml2

[Alexandre Ganea via cfe-dev]

Agreed with Adrian. The issue boils down to libXml2 not having an official release channel on Windows, and being a pain to compile. Can we maybe provide a .py script as part of LLVM, so that users can build libXml2 themselves? (based on the solution Petr provided)

De : Adrian McCarthy <amccarth at google.com>
Envoyé : August 24, 2021 1:22 PM
À : Ben Boeckel <ben.boeckel at kitware.com>
Cc : Alexandre Ganea <alexandre.ganea at ubisoft.com>; clang developer list <cfe-dev at lists.llvm.org>
Objet : Re: [cfe-dev] Cannot CMake self-hosted clang on Windows for lack of libxml2

>  Could an issue please be filed about this? CMake tries hard to not break
backwards compat, though we're not perfect (and we can't fix what we're
not aware of).

I appreciate that, but I don't think this is a CMake bug.

In this instance, llvm-mt is supposed to be a cross-platform drop-in alternative for mt.exe.  In theory, it shouldn't matter which one CMake selects.  And, in fact, the point of a self-hosted build is to use the LLVM tool chain.  The fact that llvm-mt's dependencies aren't met on Windows seems like an LLVM problem, either in the tool itself or in the documentation about how to set up the development environment.

[Rant about the near-infinite size of LLVM's "supported" configuration space elided, for now.]


On Mon, Aug 23, 2021 at 5:12 PM Ben Boeckel <ben.boeckel at kitware.com<mailto:ben.boeckel at kitware.com>> wrote:
On Mon, Aug 23, 2021 at 15:17:21 -0700, Adrian McCarthy via cfe-dev wrote:
> Yikes!  Thanks for the heads up.
>
> This is the third time I've bisected to find build configuration problems
> that affect only certain Windows configurations only to learn that it was
> (primarily) a change in our tools that broke things (retroactively).  Since
> the bot configurations aren't updated very often, it's easy for these
> problems to go unnoticed for a very long time.

*Puts on CMake developer hat*

Could an issue please be filed about this? CMake tries hard to not break
backwards compat, though we're not perfect (and we can't fix what we're
not aware of).

> It's one thing not to have hermetic builds, but it's quite another to allow
> every developer to choose from a wide range of versions for each of the
> myriad tools necessary to build the product.  The builds are so sensitive
> to so many details of the environment, it's rather amazing to me how often
> we manage to succeed.

Yes, and CMake tries not to be the bump in the road there, but we can
fix this in 3.20.6 and 3.21.2 (maybe 3.21.3, depends on how intricate
the fix is).

Thanks,

--Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210824/dbcf6bbf/attachment.html>