Re: [Boost-cmake] Analysis of the current CMake system
on Wed Jan 14 2009, troy d. straszheim troy-AT-resophonic.com wrote: Hi Brad, There is a lot to discuss here. I'll go back later and make specific comments. It'd be great to talk in person at boostcon, (boostcon rocks, by the way.) I understand/agree with a lot of your points (especially bulkiness, and the need to reduce the number of toplevel targets), in most cases because I've learned more about cmake since I implemented what is currently on the boost trunk. Brad King wrote: [snip] In summary, I'd like to help you folks address these issues. Some of the work will be in Boost's CMake code and some in CMake itself. The work will benefit both projects. We can arrange to meet at BoostCon, but we can probably get alot of discussion done on this list before then. BTW, can anyone suggest a preferred format for a BoostCon session from the boost-cmake-devs' point of view? I don't personally see a formal presentation to boost-cmake devs as being useful, there just aren't enough of us (last I checked there were three). Who are you counting? I don't think I've done anything substantial with Boost-CMake but would still be *very* interested in such a talk. -- Dave Abrahams BoostPro Computing http://www.boostpro.com ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Analysis of the current CMake system
On Wed, Jan 14, 2009 at 6:16 PM, Doug Gregor doug.gre...@gmail.com wrote: On Wed, Jan 14, 2009 at 3:02 PM, Beman Dawes bda...@acm.org wrote: On Wed, Jan 14, 2009 at 11:52 AM, Brad King brad.k...@kitware.com wrote: .. One of the goals of CMake is to let developers use their favorite native tools. Horrors! As a boost developer, the last thing in the world I want is to have to know anything about a platform's native tools. I just want to be able to enter the CMake equivalent of bjam in the directory I'm testing, and have it build and run all tests for all installed compilers. Perhaps with appropriate arguments if I only want to test with subset of the compilers, or a single test, or pass in some compiler arguments. This is exactly the argument that got us into our current build-tools mess. We've always placed so much emphasis on making things easy for Boost *developers* that we've made them extremely tough for Boost *users*. This feature---the ability to run bjam once and run everything across multiple compilers---is responsible for the majority of the damage, because we've been architecting bjam for multiple compilers at the expense of the common case of a single system compiler. We had this discussion before and decided it would be fine for boost developers if what they were running was actually just a script that just called the underlying CMake setups multiple times. But at the level of reporting, both local and on the web, there has to be a single summary available that brings together all test results. Have you tried helping a Boost newbie go through the process of building and installing Boost lately? It's extremely painful, but we don't see that pain because we've all gone through the initial hurdles of getting bjam setup just right for our own configurations. I certainly see the pain - I'm the one who does the builds for a client of mine. It is a painful mess now, that's for sure. Any progress on pre-built binaries? That's the wrong thing to optimize: we need to optimize for the case where a new user downloads Boost and wants to build/use it immediately. Those users only care about a single compiler---the one they use for their day-to-day work---and would greatly benefit from being able to use their platform-specific tools (Visual Studio, xCode, whatever). True, but they have to build several variants for that compiler, and on some platforms the 32 and 64 bit flavors are more like two separate compilers. If we're going to go through the effort of introducing a new build system, we need to focus on the user experience first and foremost. If you don't give the developers tools they can use, they won't switch to CMake. If you don't give the release managers tools they can use, they won't switch to CMake. And of course the users needs have to be met too. It is a three-legged stool. All three legs have to bear the weight, or it topples. --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Analysis of the current CMake system
on Thu Jan 15 2009, Beman Dawes bdawes-AT-acm.org wrote: Have you tried helping a Boost newbie go through the process of building and installing Boost lately? It's extremely painful, but we don't see that pain because we've all gone through the initial hurdles of getting bjam setup just right for our own configurations. I certainly see the pain - I'm the one who does the builds for a client of mine. It is a painful mess now, that's for sure. Any progress on pre-built binaries? Boostpro Computing provides them for Windows. We've just done the extra work necessary to make it fairly easy to push out a new release, and we're expecting to post a 1.37 release in the next 24 hours. That's the wrong thing to optimize: we need to optimize for the case where a new user downloads Boost and wants to build/use it immediately. Those users only care about a single compiler---the one they use for their day-to-day work---and would greatly benefit from being able to use their platform-specific tools (Visual Studio, xCode, whatever). True, but they have to build several variants for that compiler, and on some platforms the 32 and 64 bit flavors are more like two separate compilers. I think the number of actual end-users who need to build multiple variants is relatively small. Even if a company is shipping multiple versions of a product, end users are typically doing the compile-edit-debug cycle with a single compiler and variant. If we're going to go through the effort of introducing a new build system, we need to focus on the user experience first and foremost. If you don't give the developers tools they can use, they won't switch to CMake. If you don't give the release managers tools they can use, they won't switch to CMake. And of course the users needs have to be met too. It is a three-legged stool. All three legs have to bear the weight, or it topples. Good. Maybe you could be explicit about the needs that, in your view, are brought by each group? -- Dave Abrahams BoostPro Computing http://www.boostpro.com ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
