similar to: [LLVMdev] [cfe-dev] RFC: Upcoming Build System Changes

Hello Anton. Anton Korobeynikov <anton at korobeynikov.info> writes: >> If having two build systems is a problem, just standardize on cmake. > Does cmake support cross-compilation? Can it cross-compile LLVM ? Yes: http://www.llvm.org/docs/CMake.html#cross The main difference is that you use a configuration file instead of passing arguments on the command line. Please note that

> The main difference is that you use a configuration file instead of > passing arguments on the command line. Please note that the > configuration file is for a toolset, not for a project (i.e. you don't > need to create one every time you want to cross-compile a new project > from Debian to Windows with MinGW.) Well, ok. How hard it will be to create something necessary for

Reid Kleckner <reid.kleckner at gmail.com> writes: > While eliminating duplication is one of the goals I see in this build system > change, I think the more important ones are a) simplifying the build files > and b) making the build faster. The "build files" are the Makefiles, right? And Dan's proposal will not make the cmake build any faster. So those goals are

On Fri, Oct 28, 2011 at 3:54 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Anyways, if you wish to avoid duplicating info on both Makefile and > CMakeLists.txt there is a simple solution: read and parse the Makefile > from the corresponding CMakeLists.txt. For instance, if you put the > library dependencies on the Makefile like this: > > LLVMLIBDEPS := foo zoo bar >

I wouldn't say that. I know quite a few systems here around that even try to avoid python where possible. but cmake however, as a build system, is welcomed by all of us (working as a sysop in a unix environment). I'd also (as a non-llvm-dev but llvm-userdev) vote for NOT reinventing the wheel but to use the tool the fits you the best, personally that's even cmake, too. it has a well

@Tobias The poly docs build step is still failing, but due to a bug in the particular version of Sphinx used by the www-scripts builder. This seems like something best worked around inside poly. The builds take place hourly and their output is reported on the www-scripts at lists.llvm.org mailing list. On Thu, May 25, 2017 at 12:58 AM, Tobias Grosser <tobias.grosser at inf.ethz.ch > wrote:

I'm going to briefly summarize my responses here. On Fri, Oct 28, 2011 at 9:56 AM, Chris Lattner <clattner at apple.com> wrote: > On Oct 28, 2011, at 12:54 AM, Óscar Fuentes wrote: >> Anyways, if you wish to avoid duplicating info on both Makefile and >> CMakeLists.txt there is a simple solution: read and parse the Makefile >> from the corresponding CMakeLists.txt.

+1 We build our OpenCL SDK (for windows and Linux) using CMake. We’ve integrated LLVM’s Cmake hierarchy into our own (customizing LLVM external parameters like build and install directories, added passes, etc) Migrating LLVM’s build system from CMake to something else would require us to change the way we currently do things. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

Anton, please add release_32 also in; clang-tools-extra compiler-rt dragonegg libcxxabi lldb They have release_32 in svn. I don't know they might be released, though. And, could you suppress generating refs/heads/svn-tags and prune them for now? I am sure that orphan branches will stress the llvm.org server to begin git-pack-ing whole tree. ...Takumi 2012/11/15 Anton Korobeynikov

Should be there On Fri, Nov 16, 2012 at 3:00 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Anton, please add release_32 also in; > > clang-tools-extra > compiler-rt > dragonegg > libcxxabi > lldb > > They have release_32 in svn. I don't know they might be released, though. > > And, could you suppress generating refs/heads/svn-tags and prune them

On Oct 27, 2011, at 10:55 PM, Chris Lattner wrote: > On Oct 27, 2011, at 6:34 PM, Chandler Carruth wrote: > >> I have a very high level comment, and you may be able to directly shed light on it before I dig into a lot more detail. >> >> Why not simply standardize on CMake? It's not my favorite tool, but it seems to work well, we have established usage of it, and

On Apr 2, 2012, at 3:07 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> Ah OK. I would have loved to have such a tool, but as a non-clang >> expert, I can obviously not judge if it is suited. Maybe you are aware >> of other projects suitable for GSoC, > But still many things in "Use clang libraries to implement better > versions of existing

On Fri, Oct 28, 2011 at 9:56 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Reid Kleckner <reid.kleckner at gmail.com> writes: <snip> > Keep in mind that, if Dan goes ahead his plans, tinkering on any build > system would require knowledge of both of them plus the python > scripts. That's adding complexity, quite a lot. This argument might make sense if you

Hi, I'm interested in GSOC in general, but I missed this roundtable unfortunately. Any summary from this session? Thanks, -- Mehdi On Mon, Oct 21, 2019 at 7:19 PM Vassil Vassilev via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Round table on GSoC is a very good idea. Thanks for organizing! > > -- Vassil > On 10/22/19 12:51 AM, Anton Korobeynikov via cfe-dev wrote:

210 issues have been filed on github so far. That's negligible compared to the total number we have, so a minor additional effort for those seems acceptable if we can't actually clean them out and reuse the numbers. So suppose we start with bugzilla issue #211 and migrate the issues to github one at a time, in order. That would preserve the existing bug numbering and all existing bugs,

I have a very high level comment, and you may be able to directly shed light on it before I dig into a lot more detail. Why not simply standardize on CMake? It's not my favorite tool, but it seems to work well, we have established usage of it, and several people involved in the project who understand how it works. It doesn't seem like a significantly more burdensome dependency than Python

Dean, Please add this to OpenProjects page. On Tue, Feb 20, 2018 at 6:49 AM, Dean Michael Berris via cfe-dev <cfe-dev at lists.llvm.org> wrote: > Hi Tanya, > > Is it too late to get some smaller projects for XRay in there? > > Here's two: > > XRay Function Coverage Mode: Implementing an XRay mode to gather function > call coverage information. This will be

Will someone in charge please complete LLVM's page at google-melange.com? Without that LLVM is missing in the list of participants: http://www.google-melange.com/gsoc/accepted_orgs/google/gsoc2013 On Mon, Apr 8, 2013 at 11:11 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Dear All > > I'd like to announce that this year LLVM Compiler Infrastructure >

Óscar Fuentes <ofv at wanadoo.es> writes: > greened at obbligato.org (David A. Greene) writes: > >> Hmm...it's a build system, right? There's not much to add, really. >> Build systems should be really simple. All they need is dependencies >> and rules to build stuff. > > Oh, yes, sure, you're right. <g> Can't tell if you're being

At Microsoft, we believe that we gain a competitive advantage by making the Visual Studio versioning story as complicated as possible. To wit: The compiler in the first VS 2015 release was version 19.00. For each update/hotfix release, we bumped that version by .01. When VS 2017 was released, we decided to keep the major compiler version the same to signify backwards-binary-compatibility with the