search for: steveire

Mason Wheeler wrote: >>From: David Röthlisberger <david at rothlis.net> >>Subject: Re: [LLVMdev] [cfe-dev] is configure+make dead yet? >> >>If the following statement is true, then which build system to choose >>is a no-brainer: > >>> cmake, while ugly, can be made to support all of our use cases. There >>> are some use cases that

...ng, because they are looking for a dylib that doesn’t exist. Could you please take a look? Thanks -Juergen On Feb 10, 2014, at 2:34 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Steve, excuse me to respond you partially. > > 2014-02-10 18:54 GMT+09:00 Stephen Kelly <steveire at gmail.com>: >> NAKAMURA Takumi wrote: >> >>> [CMake] Introduce llvm_add_library(). >> >> I recommend moving away from wrappers like this. They indicate that either >> CMake is not providing the interfaces needed, or not propagating them, or >> th...

...ase take a look? >> >> Thanks >> >> -Juergen >> >> On Feb 10, 2014, at 2:34 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: >> >> Steve, excuse me to respond you partially. >> >> 2014-02-10 18:54 GMT+09:00 Stephen Kelly <steveire at gmail.com>: >> >> NAKAMURA Takumi wrote: >> >> [CMake] Introduce llvm_add_library(). >> >> >> I recommend moving away from wrappers like this. They indicate that either >> CMake is not providing the interfaces needed, or not propagating them...

NAKAMURA Takumi wrote: > [CMake] Introduce llvm_add_library(). I recommend moving away from wrappers like this. They indicate that either CMake is not providing the interfaces needed, or not propagating them, or that they exist but are not used. Such wrappers don't parse the arguments in the same way as the wrapped command etc. Wrappers are not good API proxies. Additionally, you put

Hello, I work on CMake upstream. I'd like to find out in what ways CMake upstream does not fit the needs of llvm/clang, and then fill those gaps. The recent update of the minimum version to CMake 2.8.8 is a good start. Before being able to assess what is missing, it should be ensured that the current codebase is as modern as the minimum version allows, and it needs to be cleaned up. 1)

...may be interested. Please send any tips or feedback to <asb at asbradbury.org>, or @llvmweekly or @asbradbury on Twitter. ## News and articles from around the web Steve Ire has written a blog post about [using Clang through the cindex API to automatically generate Python bindings](https://steveire.wordpress.com/2016/05/18/generating-python-bindings-with-clang/). He also makes use of [SIP](https://www.riverbankcomputing.com/software/sip/intro). Krister Walfridsson has written a wonderfully clear post on [C's type-based aliasing rules](http://kristerw.blogspot.co.uk/2016/05/type-based-ali...

On Wed, Nov 28, 2018 at 6:25 PM Chris Lattner via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Generally no IMO, because the cases that produce optional are not obvious. > Just to say, +1 from me too. > > > * Can we use auto in c++14 lambda arguments with llvm::find_if(C, > [](const auto& i) { ... }) for example? > > * We need to use auto for structured

On Dec 16, 2018, at 11:44 AM, Stephen Kelly via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 25/11/2018 14:43, Stephen Kelly via llvm-dev wrote: >> However this is a proposal for more modern thinking regarding the permissiveness of auto in LLVM codebases. >> Currently the rule on the use of auto is here: > > Hi, > > Thanks for the input on this topic,

Hi, Following on from another thread (Long-Term Support for LLVM Projects Extension to Build System) I'd like to discuss the testing of the exported LLVM CMake targets which can be used by consumers of LLVM as documented in [1]. Right now we don't test this feature **at all** and as a result it has been or is * broken in trunk * broken by those packaging LLVM * broken in the official