similar to: [LLVMdev] [RFC] July Update: Progress report on CMake build system's ability to replace autoconf

Hi Chris, Looking forward to continued support for CMake! Along that note, I wanted to add one bug to your list of things to track, which to me seems up your alley but maybe was filed in the wrong bucket (or is actually someone else's problem). Bug 24154 - CMake shared files are broken in llvm-3.7-dev Cheers, Brenden On Wed, Jul 29, 2015 at 1:20 PM Chris Bieneman <beanz at

Hi Brenden, Thanks for the heads up. I don’t expect that to be a blocker for deprecating autoconf because autoconf doesn’t have an equivalent of LLVMExports.cmake. That said it is a real issue and I’ll track it with the other issues on this list, and I’ve added it as a dependency on the meta bug (PR15732) to make it easier to keep track of. Thanks, -Chris > On Jul 29, 2015, at 4:48 PM,

Hi LLVMDev, There’s been a good bit of progress this month, and with the dev meeting later this week I thought I’d send out a second update. There are only two outstanding blocking issues that don’t have patches proposed, PR 21568 & PR 23947. I would greatly appreciate if someone who works on Mips would take a look at PR 23947. The following issues have been marked as fixed since the last

Hi all, Time for another update on the status of the CMake build system. Completed: * Bug 18496 - [cmake] .S assembly files not compiled by cmake in libclang_rt.ARCH * Bug 22725 - lldb build with cmake fails with "Program error: Invalid parameters entered, -h for help. " * Update GettingStarted to prefer CMake Still Outstanding: * Bug 14109 - CMake build for compiler-rt should use

Probably not a blocker for replacing autoconf, while at it: Bug 23468 - LLVM_OPTIMIZED_TABLEGEN does not work with Visual Studio. It makes the tablegenning really slow. 2015-05-28 18:22 GMT+03:00 Chris Bieneman <beanz at apple.com>: > Hi all, > > Time for another update on the status of the CMake build system. > > Completed: > * Bug 18496 - [cmake] .S assembly files not

> On May 28, 2015, at 8:37 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > > Probably not a blocker for replacing autoconf, while at it: > Bug 23468 - LLVM_OPTIMIZED_TABLEGEN does not work with Visual Studio. > It makes the tablegenning really slow. This is actually a feature of the CMake build system that the autoconf one doesn’t have, so this is not related to

It seems the fix for Bug 19462 causes my stand-alone build of Clang to die with CMake Error at CMakeLists.txt:528 (install): install EXPORT given no DESTINATION! Any pointers? On Thu, May 28, 2015 at 8:22 AM, Chris Bieneman <beanz at apple.com> wrote: > Hi all, > > Time for another update on the status of the CMake build system. > > Completed: > * Bug 18496 - [cmake]

Thanks! 2015-05-28 18:56 GMT+03:00 Chris Bieneman <beanz at apple.com>: > > On May 28, 2015, at 8:37 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > > Probably not a blocker for replacing autoconf, while at it: > Bug 23468 - LLVM_OPTIMIZED_TABLEGEN does not work with Visual Studio. > It makes the tablegenning really slow. > > > This is actually a

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

I sent out a patch for review. http://reviews.llvm.org/D10102 <http://reviews.llvm.org/D10102> -Chris > On May 28, 2015, at 9:48 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > > Thanks! > > 2015-05-28 18:56 GMT+03:00 Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>>: > >> On May 28, 2015, at 8:37 AM, Yaron Keren

Do they really allways put them into Release/bin or rather $<CONFIG>/bin? -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut für Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de |

Both Release and $CONFIG tblgen are built but the Release one is always used. At least with Visual C++ the Release tblgen is much faster than the Debug one. 2015-05-29 9:37 GMT+03:00 Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>: > Do they really allways put them into Release/bin or rather $<CONFIG>/bin? > > > > -- >

There has been a lot of progress since I first sent out an email recapping the status of replacing autoconf, so I thought I’d send an update. Completed: * Bug 15493 - No option to build shared libLLVM-version.so in CMake * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable * Bug 18722 - Option to use CMake with libc++ to compile clang * Bug 21560 - Add support to cmake for

That it’s faster is no surprise. Is the Release tblgen even built when you build in Debug mode? Otherwise this introduces the need to build Release before Debug. -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut für Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49

Yes, that's the idea, when you -DLLVM_OPTIMIZED_TABLEGEN=ON tblgen is built in Release in addition to whatever /property:Configuration= is. 2015-05-29 10:03 GMT+03:00 Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>: > That it’s faster is no surprise. Is the Release tblgen even built when > you build in Debug mode? Otherwise this

Takumi fixed that issue with r238628. Thanks, -Chris > On May 29, 2015, at 4:24 PM, Steve King <steve at metrokings.com> wrote: > > It seems the fix for Bug 19462 causes my stand-alone build of Clang to die with > > CMake Error at CMakeLists.txt:528 (install): > install EXPORT given no DESTINATION! > > Any pointers? > > On Thu, May 28, 2015 at 8:22 AM,

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

As somebody who's currently hosting LLVM on a platform (OpenVMS Itanium) that has configure but not a working CMake (we're working to fix that but there are some tricky issues), I would appreciate if you didn't scrub the existence of configure from the source or the documentation. Perhaps keep pointers to the older pages and link to them from the downloads pages or something with an

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-----

> 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