search for: schism

On Mon, Oct 6, 2014 at 5:00 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Oct 6, 2014, at 3:44 PM, Rui Ueyama <ruiu at google.com> wrote: > > Looks like most people in this thread support using LLVM style in LLD. I > also had an offline discussion and many people wanted to have one coding > style in all LLVM projects. So I'm convinced that we should do that.

...e ongoing contributions to LLVM by preserving low barrier to entry for contributors. - protect users of LLVM code by providing explicit patent protection in the license. - protect contributors to the LLVM project by explicitly scoping their patent contributions with this license. - eliminate the schism between runtime libraries and the rest of the compiler that makes it difficult to move code between them. Here we are discussing what the best end game is -- not the logistics of how to get from here to there. The email from last year proposed relicensing the LLVM project under the Apache 2 Lice...

...ntil now the thread has been about “formatting”. You suggested renaming every variable in the project! If that's what it takes. > On Oct 6, 2014, at 5:37 PM, Chris Lattner <clattner at apple.com> wrote: >> Right. Specifically, why is it for the “greater good” to perpetuate a schism between lld and the rest of llvm? >> > > Well to turn this around, why is llvm maintaining a schism with the rest of the C++ world? That is, lld (and probably lldb) is more like all the other C++ conventions in the world than llvm is. If llvm had conventions like every other convent...

...means that people using 2003 is left in the cold and people who only have 2008 must convert the project files and, most important, can't contribute to the maintenance of the VC++ build. CMake can generate Visual Studio project files (for all three versions) and NMake makefiles. This solves the schism among Visual Studio users. Furthermore, CMake can replace `configure' and generate gmake makefiles, project files for XCode, etc. In just an afternoon I hacked CMake specifications for the LLVM libraries and successfully built the fibonacci example. Most of the time consisted on just waiting...

...very personal of me. Ron babe, TNG fork was a preventable disaster. I think the problem is a lot of us are sitting on our thumbs and letting Jeremy and the band pick out all the problems for us. When schedules get too tight and there are different priorities there's always a gang leader for a schism. That it plays into the hands of the great Satan duplicating the effort and splitting the community is a matter of grave concern for all. M$ will underbid any serious attempt at a mass migration to open source with hefty rebates, and there's little we can do against that except strive to be a s...

...to LLVM by preserving low barrier to entry for contributors. >> - protect users of LLVM code by providing explicit patent protection in the license. >> - protect contributors to the LLVM project by explicitly scoping their patent contributions with this license. >> - eliminate the schism between runtime libraries and the rest of the compiler that makes it difficult to move code between them. >> - ensure that LLVM runtime libraries may be used by other open source and proprietary compilers. >> >> Here we are discussing what the best end game is -- not the logistic...

...rage ongoing contributions to LLVM by preserving low barrier to entry for contributors. - protect users of LLVM code by providing explicit patent protection in the license. - protect contributors to the LLVM project by explicitly scoping their patent contributions with this license. - eliminate the schism between runtime libraries and the rest of the compiler that makes it difficult to move code between them. - ensure that LLVM runtime libraries may be used by other open source and proprietary compilers. Here we are discussing what the best end game is -- not the logistics of how to get from here t...

...to LLVM by preserving low barrier to entry for contributors. >> - protect users of LLVM code by providing explicit patent protection in the license. >> - protect contributors to the LLVM project by explicitly scoping their patent contributions with this license. >> - eliminate the schism between runtime libraries and the rest of the compiler that makes it difficult to move code between them. > > Hi Chris, > let me go back to this with some of the thoughts from the last Berlin > Social. Thanks! FWIW, if you or anyone else is going to be at the LLVM Dev Meeting and are...

On May 11, 2008, at 9:36 AM, Óscar Fuentes wrote: > > Not that I sympathize with the OP's manners but... > > Bill Wendling <isanbard at gmail.com> writes: >> >> That's only a convenience. GCC generates assembly code too and calls >> the assembler and linker as part of it's execution. You are perfectly >> able to call the assembler & linker

...ibutions to LLVM by preserving low barrier to entry for contributors. > - protect users of LLVM code by providing explicit patent protection in the license. > - protect contributors to the LLVM project by explicitly scoping their patent contributions with this license. > - eliminate the schism between runtime libraries and the rest of the compiler that makes it difficult to move code between them. > - ensure that LLVM runtime libraries may be used by other open source and proprietary compilers. > > Here we are discussing what the best end game is -- not the logistics of how...

...entally be granted to LLVM (through “scope creep”). I will not make any claims about whether these fears are founded or not, but I will observe that this is a serious and current problem for the community. 2) We cannot easily move code from LLVM to compiler_rt (for example). We currently have a schism between the compiler code (licensed under the UIUC license) and the runtime library code (licensed under the UIUC & MIT license). This schism exists because the UIUC license carries what is known as a “binary attribution clause”. This clause requires someone to acknowledge their use of LLVM i...

Not that I sympathize with the OP's manners but... Bill Wendling <isanbard at gmail.com> writes: > On May 10, 2008, at 7:55 PM, kr512 wrote: > >> See how gcc is invoked to generate the final executable >> file. This means LLVM is an incomplete backend, >> unfortunately. >> > That's only a convenience. GCC generates assembly code too and calls

...means that people using 2003 is left in the cold and people who only have 2008 must convert the project files and, most important, can't contribute to the maintenance of the VC++ build. CMake can generate Visual Studio project files (for all three versions) and NMake makefiles. This solves the schism among Visual Studio users. Furthermore, CMake can replace `configure' and generate gmake makefiles, project files for XCode, etc. In just an afternoon I hacked CMake specifications for the LLVM libraries and successfully built the fibonacci example. Most of the time consisted on just waiting...