> On Feb 7, 2019, at 11:01 AM, paul.robinson at sony.com wrote: > > It seems the CMake changes have landed; but the docs are still a bit out of date? > CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN. > > I’m. Not sure how one updates the website’s docs, I had assumed the RST files would automatically get rebuilt and pushed? Agreed we want it fixed, but I don’t think it’s good reason to revert since the error message is pretty clear. > > Huh. I also thought the website was kept up to date automagically, which is why I looked at the website not the source; but the source does have the new option. Never mind… <> > > Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN. If that's going to be a permanent deficiency, it should be mentioned in the docs as well. > > Someone mentioned MSVC was having issues that way? https://reviews.llvm.org/rL353374#624722 <https://reviews.llvm.org/rL353374#624722> > That seems like general badness in the way that configuration is set up, no? It should probably get fixed separately > > "Somebody else ought to get around to fixing that someday so why bother documenting something that might eventually change" does not seem like a very robust argument. I've answered a pile of questions from newcomers lately, I would prefer that people not add new reasons for the documentation to lie about how things work currently. Or more accurately, don't work, because you can't currently use both those options at once. > > If someone does change how the optimized-tablegen feature works (or eliminates it entirely), surely they would be able to update the documentation accordingly? > So, please fix.Can you clarify what you’re asking for exactly, and who you’re asking it from? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190207/d81e7495/attachment.html>
This was easy enough to fix, so I did so in r353463. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: JF Bastien <jfbastien at apple.com> Date: Thursday, February 7, 2019 at 12:30 PM To: "paul.robinson at sony.com" <paul.robinson at sony.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC] migrating past C++11 On Feb 7, 2019, at 11:01 AM, paul.robinson at sony.com<mailto:paul.robinson at sony.com> wrote: It seems the CMake changes have landed; but the docs are still a bit out of date? CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN. I’m. Not sure how one updates the website’s docs, I had assumed the RST files would automatically get rebuilt and pushed? Agreed we want it fixed, but I don’t think it’s good reason to revert since the error message is pretty clear. Huh. I also thought the website was kept up to date automagically, which is why I looked at the website not the source; but the source does have the new option. Never mind… Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN. If that's going to be a permanent deficiency, it should be mentioned in the docs as well. Someone mentioned MSVC was having issues that way? https://reviews.llvm.org/rL353374#624722<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_rL353374-23624722&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=jXkuL7NOOygyZEXTmkYhOIbDwj1UhwVNfH8WnSmowIA&s=UT6L9JA4kVtR0MRecFgpu3lQ6GkA1YKsZmhJshQ0Ynw&e=> That seems like general badness in the way that configuration is set up, no? It should probably get fixed separately "Somebody else ought to get around to fixing that someday so why bother documenting something that might eventually change" does not seem like a very robust argument. I've answered a pile of questions from newcomers lately, I would prefer that people not add new reasons for the documentation to lie about how things work currently. Or more accurately, don't work, because you can't currently use both those options at once. If someone does change how the optimized-tablegen feature works (or eliminates it entirely), surely they would be able to update the documentation accordingly? So, please fix. Can you clarify what you’re asking for exactly, and who you’re asking it from? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190207/307d73a0/attachment.html>
> On Feb 7, 2019, at 12:59 PM, Shoaib Meenai <smeenai at fb.com> wrote: > > This was easy enough to fix, so I did so in r353463.Thanks, I agree this fixes an immediate issue but it still doesn’t fix the root cause: it sounds like this cross-compile setup loses flags that it shouldn’t be losing.> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> > Reply-To: JF Bastien <jfbastien at apple.com> > Date: Thursday, February 7, 2019 at 12:30 PM > To: "paul.robinson at sony.com" <paul.robinson at sony.com> > Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [RFC] migrating past C++11 > > > > > On Feb 7, 2019, at 11:01 AM, paul.robinson at sony.com <mailto:paul.robinson at sony.com> wrote: > > It seems the CMake changes have landed; but the docs are still a bit out of date? > CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN. > > I’m. Not sure how one updates the website’s docs, I had assumed the RST files would automatically get rebuilt and pushed? Agreed we want it fixed, but I don’t think it’s good reason to revert since the error message is pretty clear. > > Huh. I also thought the website was kept up to date automagically, which is why I looked at the website not the source; but the source does have the new option. Never mind… > > Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN. If that's going to be a permanent deficiency, it should be mentioned in the docs as well. > > Someone mentioned MSVC was having issues that way? https://reviews.llvm.org/rL353374#624722 <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_rL353374-23624722&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=jXkuL7NOOygyZEXTmkYhOIbDwj1UhwVNfH8WnSmowIA&s=UT6L9JA4kVtR0MRecFgpu3lQ6GkA1YKsZmhJshQ0Ynw&e=> > That seems like general badness in the way that configuration is set up, no? It should probably get fixed separately > > "Somebody else ought to get around to fixing that someday so why bother documenting something that might eventually change" does not seem like a very robust argument. I've answered a pile of questions from newcomers lately, I would prefer that people not add new reasons for the documentation to lie about how things work currently. Or more accurately, don't work, because you can't currently use both those options at once. > > If someone does change how the optimized-tablegen feature works (or eliminates it entirely), surely they would be able to update the documentation accordingly? > So, please fix. > > Can you clarify what you’re asking for exactly, and who you’re asking it from?-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190207/8ad0e6c8/attachment.html>