similar to: [LLVMdev] Downstream distributions as first class citizens in the LLVM repository

On Fri, Oct 18, 2013 at 06:47:55PM -0400, Tom Stellard wrote: > On Fri, Oct 18, 2013 at 07:09:47PM +0200, Joerg Sonnenberger wrote: > > Hi all, > > I mentioned this idea yesterday on IRC already and would like to discuss > > in the greater context of the mailing list. NetBSD is about to import > > LLVM and Clang into its repository; FreeBSD already has done that a >

On Sat, Oct 19, 2013 at 01:07:49AM +0200, Joerg Sonnenberger wrote: > On Fri, Oct 18, 2013 at 06:47:55PM -0400, Tom Stellard wrote: > > On Fri, Oct 18, 2013 at 07:09:47PM +0200, Joerg Sonnenberger wrote: > > > Hi all, > > > I mentioned this idea yesterday on IRC already and would like to discuss > > > in the greater context of the mailing list. NetBSD is about

On Fri, Oct 18, 2013 at 07:09:47PM +0200, Joerg Sonnenberger wrote: > Hi all, > I mentioned this idea yesterday on IRC already and would like to discuss > in the greater context of the mailing list. NetBSD is about to import > LLVM and Clang into its repository; FreeBSD already has done that a > while ago. This creates some interesting maintainance questions. FreeBSD > has

On Fri, Oct 18, 2013 at 07:28:28PM -0400, Tom Stellard wrote: > On Sat, Oct 19, 2013 at 01:07:49AM +0200, Joerg Sonnenberger wrote: > > On Fri, Oct 18, 2013 at 06:47:55PM -0400, Tom Stellard wrote: > > > On Fri, Oct 18, 2013 at 07:09:47PM +0200, Joerg Sonnenberger wrote: > > > > Hi all, > > > > I mentioned this idea yesterday on IRC already and would like

<snip /> May I just add a few points 1) Won't get rid of forks - ever.. forget it 2) Branches are "free" - having a single branch for dumping things is unlikely to suit the needs of all the work by everyone 3) Having things consolidated in one more or less easy to find place is better than all over the damn place. ------------ I'd vote to give FBSD and anyone

On Sat, Oct 19, 2013 at 06:47:51AM +0700, "C. Bergstr?m" wrote: > <snip /> > > May I just add a few points > > 1) Won't get rid of forks - ever.. forget it > 2) Branches are "free" - having a single branch for dumping things is > unlikely to suit the needs of all the work by everyone I think that having a single stable branch would be the most

On Oct 18, 2013, at 7:07 PM, Tom Stellard <tom at stellard.net> wrote: > On Sat, Oct 19, 2013 at 06:47:51AM +0700, "C. Bergstr?m" wrote: >> <snip /> >> >> May I just add a few points >> >> 1) Won't get rid of forks - ever.. forget it >> 2) Branches are "free" - having a single branch for dumping things is >>

On 19 Oct 2013, at 04:37, Chris Lattner <clattner at apple.com> wrote: > I agree. I don't see how a concept of "official vendor branches" is better than the concept of "stable" branches that take bugfixes. I think it would be simple and work well to just have vendors ask to get patches merged into 3.3.x or 3.4.x (whichever they are based on) stabilization

On Mon, Oct 03, 2016 at 09:04:15AM +0200, Joerg Sonnenberger via llvm-dev wrote: > On Sun, Oct 02, 2016 at 11:09:08PM +0000, Zachary Turner via llvm-dev wrote: > > The BSDs don't seem as much of an issue. FreeBSD 10 and 11 both have LLVM > > 3.9 and GCC 4.9. NetBSD 6.1.5 and 7.0 both have GCC 5.3 and LLVM 3.8. > > Open BSD has a very old GCC, but distrowatch claims that

On 2 Nov 2014, at 14:17, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > Requiring cmake for NetBSD is not acceptable as it is almost as heavy as > a C++ compiler itself. That said, I don't really care about the > Makefiles, just about configure and the associated loggic to craete > Config.h and friends. I would expect FreeBSD to have similar concerns. For the

On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote: >> This is a regression caused by https://reviews.llvm.org/rL323281: >> >> ------------------------------------------------------------------------ >> r323281 | wmi | 2018-01-23 23:27:57 +0000

On Sat, Oct 1, 2016 at 11:46 PM Joerg Sonnenberger via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, Oct 02, 2016 at 05:33:40AM +0000, Zachary Turner via llvm-dev > wrote: > > While GCC doesn't claim to "fully" support C++14 until 5.2 (which is only > > about 1 year old), you can get all of the above features with GCC 4.9 > > I do care quite a

Am Fr., 5. Juli 2019 um 07:01 Uhr schrieb Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org>: > > On Fri, Jul 05, 2019 at 10:43:12AM +0000, Simon Tatham via llvm-dev wrote: > > But before I do that, I wanted to check whether there would be any > > objection on grounds of build dependencies. Is it acceptable to require Python > > as part of the normal build

All the tools in ./BuildTools/Release+Asserts/bin/ Are host tools. Since I'm not doing the make install on the target, then strip does not know about these. It knows enough to install these as xxx-host but not enough to not call strip. On 02/27/2014 06:19 AM, Joerg Sonnenberger wrote: > On Thu, Feb 27, 2014 at 08:53:20AM -0500, Ed Maste wrote: >> On 27 February 2014 00:05,

On Sun, Nov 10, 2013 at 01:42:24PM +0000, Alp Toker wrote: > |#undef NetBSD|| > ||#undef mips|| > ||#undef sparc|| > ||#undef INT64_MAX|| > ||#undef alloca| > > This is not OK to do globally -- even if LLVM doesn't care about the > definition, maybe embedding applications or OS headers do? Given that 3 of the 5 #undefs are directly relevant for me -- they exist

On 27 February 2014 00:05, Simon Atanasyan <simon at atanasyan.com> wrote: > > Install tool invokes strip. GNU install allows to configure which > strip to use (--strip-program). In general (for example on FreeBSD) it > is not possible and install always runs just 'strip'. In case of > cross-compilation that leads to the error. Actually it is possible on FreeBSD --

The BSDs don't seem as much of an issue. FreeBSD 10 and 11 both have LLVM 3.9 and GCC 4.9. NetBSD 6.1.5 and 7.0 both have GCC 5.3 and LLVM 3.8. Open BSD has a very old GCC, but distrowatch claims that it also has LLVM 3.8. Going back to what Joerg said earlier. http://distrowatch.com/table.php?distribution=netbsd says NetBSD 7 ships with GCC 5.3, but Joerg said 4.8. Which is it? And even

+1 from me. But which version of 4.8.x? 4.8.0 was released in March 2013 while 4.8.5 is June 2015 (see https://gcc.gnu.org/releases.html <https://gcc.gnu.org/releases.html>) Thats an awfully long time between those dates, so i can’t imagine everyone being on 4.8.5, but shouldn’t we aim for the highest possible one if we’re bumping versions anyway? Looking at Ubuntu 14.04 LTS

On Thu, 11 Jul 2019 at 21:44, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > That's what I said. The cmake based build system needs it. LIT is > optional. It is entirely feasible to have a custom build system and no > Python at all. It would be quite painful to break that. To be explicit (and correct me if I misstate facts), NetBSD wants to build Clang

On Mon, Jun 01, 2015 at 10:52:20AM -0700, Marshall Clow wrote: > P.S. recent gcc (at least 4.8.x and later) make optimizations based on > this UB (i.e, if you pass a pointer to memcpy, then it can't be NULL). BTW, this seems to be more an issue with glibc adding the tagging and not behavior of GCC itself. Joerg