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

Can we just ship the source for libxml2 in the repository and build it from
source if it is not found? A quick google tells me that it’s MIT licensed so
perhaps it wouldn’t be too controversial.

From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Adrian
McCarthy via cfe-dev
Sent: Tuesday, August 24, 2021 10:22 AM
To: Ben Boeckel <ben.boeckel at kitware.com>
Cc: clang developer list <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] Cannot CMake self-hosted clang on Windows for lack of
libxml2


WARNING: This email originated from outside of Qualcomm. Please be wary of any
links or attachments, and do not enable macros.
>  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/llvm-dev/attachments/20210824/7e422341/attachment.html>

I was thinking about using CMake's ExternalProject to optionally fetch and
build zlib and libxml2 from source, that might be more palatable than
including libxml2 in LLVM repository?

On Tue, Aug 24, 2021 at 10:33 AM Chris Tetreault via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Can we just ship the source for libxml2 in the repository and build it
> from source if it is not found? A quick google tells me that it’s MIT
> licensed so perhaps it wouldn’t be too controversial.
>
>
>
> *From:* cfe-dev <cfe-dev-bounces at lists.llvm.org> *On Behalf Of
*Adrian
> McCarthy via cfe-dev
> *Sent:* Tuesday, August 24, 2021 10:22 AM
> *To:* Ben Boeckel <ben.boeckel at kitware.com>
> *Cc:* clang developer list <cfe-dev at lists.llvm.org>
> *Subject:* Re: [cfe-dev] Cannot CMake self-hosted clang on Windows for
> lack of libxml2
>
>
>
> *WARNING:* This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
>
> >  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>
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210824/6382533c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3996 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210824/6382533c/attachment.bin>