> > - Using CMake for the release binaries. I think I promised we'd do > > this for 3.7. I haven't actually started looking at this yet, but I'm > > still optimistic. > > I'm absolutely in agreement with this. Most of us already use CMake > for development, a lot of the buildbots are based on it and I think we > all agree that autoconf is deprecated. Makes no sense to still use it > for releases.I have mixed opinions on it. For the 32-bit Mips packages I normally do it's definitely a good thing (it allows me to ship sanitizers for one). However, I'm hoping to do Mips64 packages too and I recently discovered cmake problems with Mips64 and find_library(). I don't think this should stop everyone switching over to cmake but it would be good to retain the option of autoconf for a bit longer.> 2. Check that the things you want to build are actually build. The > script checks out everything (including dragonegg and libc++), but my > final binaries never had any of them. Not even compiler-rt. This one I > *will* start caring *very* soon. I'd like to have both RT and libcxx > for 3.7.I was surprised by the lack of compiler-rt in the Mips packages too. It turned out that only X86 built compiler-rt in an autoconf-based build.
On 23 June 2015 at 15:40, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:> I have mixed opinions on it. For the 32-bit Mips packages I normally do it's definitely a good thing (it allows me to ship sanitizers for one). However, I'm hoping to do Mips64 packages too and I recently discovered cmake problems with Mips64 and find_library(). I don't think this should stop everyone switching over to cmake but it would be good to retain the option of autoconf for a bit longer.That's a good point.> I was surprised by the lack of compiler-rt in the Mips packages too. It turned out that only X86 built compiler-rt in an autoconf-based build.Because I haven't integrated RT and libcxx well enough into Clang on ARM/AArch64, I haven't bothered getting them in the binary tarball. Our binary distribution was more of a proof of validation than drop-in replacement for anything, anyway. I normally let the job of getting all the deps in the right place for distro folks. But now that we are validating them all on both ARM and AArch64, it's about time to make sure they work well in the binary distribution as well. But I can't do that using autoconf. cheers, --renato
On Tue, Jun 23, 2015 at 7:56 AM, Renato Golin <renato.golin at linaro.org> wrote:> On 23 June 2015 at 15:40, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: >> I have mixed opinions on it. For the 32-bit Mips packages I normally do it's definitely a good thing (it allows me to ship sanitizers for one). However, I'm hoping to do Mips64 packages too and I recently discovered cmake problems with Mips64 and find_library(). I don't think this should stop everyone switching over to cmake but it would be good to retain the option of autoconf for a bit longer. > > That's a good point.I started looking at the script yesterday, and my plan is to make it capable of using both cmake and autoconf for now, since e.g. compiler-rt doesn't build with CMake on Darwin. - Hans