similar to: [LLVMdev] RFC: Timeline for deprecating the autoconf build system?

Hello, thank you for the thoughts. > Have you seen the docs for CMake3.0 [1] (see cmake-buildsystem > especially)? They certainly aren't perfect but they are considerably > better than what was there before. Okay, the documentation has come a long way since 3.0 although it still needs a bit of polish. > I wouldn't say that much "important functionality is plain

> On Oct 31, 2014, at 4:45 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Fri, Oct 31, 2014 at 4:31 PM, Bob Wilson <bob.wilson at apple.com <mailto:bob.wilson at apple.com>> wrote: > >> On Oct 31, 2014, at 4:19 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: >> >> >>

> On Nov 9, 2015, at 3:21 PM, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On 11/9/15 4:02 PM, John Reagan via llvm-dev wrote: >> Keeping the documentation with large warnings is sufficient. It >> would at least let somebody then grab an older version's makefiles if >> they are so inclined/interested. I have no problem

On 11/9/15 5:49 PM, John Reagan wrote: > That would be fine with me. I just don't want some new visitor to > come along and see "CMake only" and get discouraged and leave. Well, it is going to be "CMake only". Anyone who depends on autotools is going to be stuck on whatever the last revision is that we shipped with it. And I really don't see it being feasible

Keeping the documentation with large warnings is sufficient. It would at least let somebody then grab an older version's makefiles if they are so inclined/interested. I have no problem with you yanking the files, just the fact that older versions did have configure/makefiles. I only spoke up when I saw the suggestion for removing the online documentation. John -----Original Message-----

I haven't been able to figure out from this thread why this attribute is necessary at all. Anonymous or unnamed namespaces were added to C++ for this very purpose, but the ISO C++ Standard does not discuss "linkage" per-se because it is outside the scope of the language specification. But it does describes it in terms of having a hidden name which is "unique" to the

Hi Jon, > Build directories aren't easily redistributable, nor are they really meant to be. Install directories on the other hand can be, provided you build with the right options, and package together all the dependencies. > > Is there a particular reason why you want to distribute your build dir instead of your install dir? Oops, you are right: I think it's the install

On Mon, Nov 3, 2014 at 9:26 AM, Tom Stellard <tom at stellard.net> wrote: > On Fri, Oct 31, 2014 at 04:31:47PM -0700, Bob Wilson wrote: > > > > > On Oct 31, 2014, at 4:19 PM, Eric Christopher <echristo at gmail.com> > wrote: > > > > > > > > > > > > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <tom at stellard.net >

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris > Lattner via llvm-dev > Sent: Saturday, October 31, 2015 2:58 PM > To: sstewartgallus00 at mylangara.bc.ca > Cc: LLVM Developers > Subject: Re: [llvm-dev] [cfe-dev] [RFC] __attribute__((internal_linkage)) > > Hi Stewart, > > I saw this get brought up at

With respect only to '__attribute__((internal_linkage))', not 'nodebug' and other parts of this topic; does hiding "some" members and not others not introduce a violation of the ODR because some members of the class as it appears in one translation unit are not the same actual definitions as the apparently "same" members of the class in another translation unit?

Hi LLVMDev, Since my last update we’ve landed patches for these issues: * Bug 14200 - -fno-rtti not in cxxflags given by llvm-config * Bug 23746 - test-suite lacks CMake support * Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible with ldconfig On my last thread Jonathan Roelofs pointed out that there is a workaround for Bug 21568 (Cannot add rpath), so I’m making it

Hi Evgenii, I was wondering what the status is of your work to attach "internal_linkage" to methods of standard library classes in libc++. The following piece of code doesn't link because a symbol (string::empty) is undefined and it sounds like your work might fix the linkage error I'm seeing. $ cat test1.cpp #include <string> #include <functional> int main() {

On Thu, May 23, 2013 at 6:01 AM, Jean-Daniel Dupas <devlists at shadowlab.org>wrote: > If you want to build a clang version that target x86 and ARM on an x86 > machine and your actual compiler does not support compiling for ARM, you > have to use the just built clang. > Using the just-built-clang will only work if compiler-rt has access to each target's sysroot.

So, we’ve had this conversation a few times, and I wanted to coalate a status report for all the interested parties. Here's the outstanding work and my (not necissarily correct) view of the status and importance of each one: * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable - There are patches on the bug that we should review, test, and land * Bug 14109 - CMake

On May 23, 2013, at 10:30 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > On Thu, May 23, 2013 at 6:01 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > If you want to build a clang version that target x86 and ARM on an x86 machine and your actual compiler does not support compiling for ARM, you have to use the just built clang. > > Using the

Hi Evgenii, I have one question about this (planned) change: what if a function is not inlined? The linker will not ODR merge them with this change, which isn’t great. What makes “internal” linkage more desirable than "linkonce_odr + visibility hidden"? — Mehdi > On Jul 12, 2016, at 6:16 PM, Evgenii Stepanov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi,

I'm trying to add ooh323c to my asterisk 1.2.7.1 install and did an svn update of asterisk-addons and followed the readme in asterisk-ooh323c and I get through the .configure with no errors. But make causes: rpath /usr/local/lib -L./ooh323c/src -version-info 1:1:0 -lpthread make: rpath: Command not found make: [libchan_h323.la] Error 127 (ignored) I'm not real sure what to try to fix

Sent from my iPhone > On Oct 31, 2014, at 17:40, Steve King <steve at metrokings.com> wrote: > >> On Fri, Oct 31, 2014 at 3:08 PM, Tom Stellard <tom at stellard.net> wrote: >> - Is there any technical reason why the remaining autoconf users can't switch >> to CMake? > > Last time I tried, the CMake build was missing some pieces required > for

RHEL5 has autoconf 2.59 and automake 1.9.6. I've managed to build the whole Xapian family by reducing the requirement to 2.59/1.9.6 in configure.ac. Omega requires docdir which can be added by hand in docs/Makefile.am: docdir = ${datadir}/doc/${PACKAGE} if !MAINTAINER_NO_DOCS dist_doc_DATA = $(RSTHTML) endif All I've done is get these packages compiled - I haven't tested in any

Le 23 mai 2013 à 14:37, David Chisnall <David.Chisnall at cl.cam.ac.uk> a écrit : > On 23 May 2013, at 07:53, Owen Anderson <resistor at mac.com> wrote: > >>> build native clang >>> build next clang with some target that supplies a sysroot and a >>> -target option to the native clang >> >> Aren't there issues with tblgen needing to be