Hi, I noticed the "boost development process / scope" thread on your list. A CMake user posted a link to your discussion. There is significant interest in the CMake community to help boost transition to CMake. Several people on the CMake list have volunteered to help, and Kitware is willing to put about 2 man weeks of effort into the conversion. I think that CMake has all the features to do what you need at this point, but if any bugs or issues are discovered during the process, we can fix them and/or provide work-arounds for the issues. I realize you have not yet decided on moving to CMake, but I thought I would put out this offer so that you could consider "free" support as one of the benefits you will receive from the port to CMake. I can see this happening in two ways. One would be for a CMake developer to create initial cmake files for boost, and get the basics working. Then, the work would be turned over to the Boost community. The other way would be to have a boost developer create the build files with help and support from the CMake community. Either way works for me. Of course, no one will want to do anything unless there is a commitment to actually use CMake. I will stay on this list while you decide, and answer any questions about CMake that may come up. Thanks, and I look forward to working with the boost community in the future. -Bill
Bill Hoffman wrote:
Hi,
I noticed the "boost development process / scope" thread on your list. A CMake user posted a link to your discussion. There is significant interest in the CMake community to help boost transition to CMake. Several people on the CMake list have volunteered to help, and Kitware is willing to put about 2 man weeks of effort into the conversion.
Wow! This is a very generous and exciting offer. Thanks, Bill!
I think that CMake has all the features to do what you need at this point, but if any bugs or issues are discovered during the process, we can fix them and/or provide work-arounds for the issues.
This is vital. We shouldn't attempt a switch unless we have reasonable assurances that CMake meets (or can be made to meet) Boost's needs. I'm encouraged by your offer, and by Doug Gregor's positive experience porting Boost to CMake a few years ago. I guess the first step would be to see if there is interest in the Boost community for switching away from our custom build solution to one that is more industry standard. (Is there? I'm interested. That makes one.) And then someone familiar with Boost's build system to put together a list of basic requirements, and go over it with a CMake expert. I guess I can start the list, and others can chime in. This is from http://www.boost.org/tools/build/v1/build_system.htm#design_criteria: * A developer adding a new library or test program must only have to add simple entries naming the source files to a text file, and not have to know anything about platform specific files. The developer should not have to supply header dependency information. * There should be a very high likelihood of builds succeeding on all platforms if a build succeeds on any platform. In other words, a developer must not be required to have access to many platforms or compilers to ensure correct builds * A user or developer adding support for a new platform or compiler should only have to add to a single file describing how to do the build for that platform or compiler, and shouldn't have to identify the files that will need to be built. * The build should rely only on tools native to the platform and compiler, or supplied via the boost download. * The details of how the build is done for a particular platform or compiler should be appropriate for that platform. * It should be possible to build multiple variants (e.g. debug/release) of a single target. * It should be possible to build multiple variants of multiple targets with multiple compilers from a single build command. * The build tools must be able to handle Boost growth issues such as identified in Directory Structure proposals and discussion. * Support for dynamic and static linking should be included. * It should be relatively straightforward to add support for a new compiler. In most cases, no modification of files used to describe existing targets should be required. * Support for compiler- and variant-specific configuration for each target * It should be possible to build targets into a directory unrelated to the source directories (they may be read-only) I'd also add: * Ability to cleanly integrate 3rd party tools (eg. so that we can use CMake to build Boost's documentation, which uses doxygen, docbook, xsltproc, Apache fop, etc., etc.) * support for Boost's automatic linking feature. * Ability to define custom build variants, (eg., so I can build a library with FOO defined, and the resulting lib gets a different name.) * Easy to add tests: compile, run, link, compile-fail, link-fail * User's can configure multiple toolsets to build with, even multple different versions of the same toolset (eg, gcc-4.0, gcc-4.1). That's just off the top of my head.
I realize you have not yet decided on moving to CMake, but I thought I would put out this offer so that you could consider "free" support as one of the benefits you will receive from the port to CMake.
That certainly greases the wheels.
I can see this happening in two ways. One would be for a CMake developer to create initial cmake files for boost, and get the basics working. Then, the work would be turned over to the Boost community. The other way would be to have a boost developer create the build files with help and support from the CMake community. Either way works for me. Of course, no one will want to do anything unless there is a commitment to actually use CMake.
After we have a list of basic requirements we should have a clearer idea of whether CMake can work for us. Better to find the obvious showstoppers before spending 2 weeks on a port! Of course, committing to use CMake is not something any one person in Boost can do.
I will stay on this list while you decide, and answer any questions about CMake that may come up.
Thanks, and I look forward to working with the boost community in the future.
Thanks. This certainly gives us something to chew on. -- Eric Niebler Boost Consulting www.boost-consulting.com
On 05/09/2007 11:05 AM, Eric Niebler wrote:
Bill Hoffman wrote: [snip]
Several people on the CMake list have volunteered to help, and Kitware is willing to put about 2 man weeks of effort into the conversion.
Wow! This is a very generous and exciting offer. Thanks, Bill!
Ditto on the thanks! [snip]
I guess I can start the list, and others can chime in. This is from http://www.boost.org/tools/build/v1/build_system.htm#design_criteria:
[snip]
I'd also add:
* Ability to cleanly integrate 3rd party tools (eg. so that we can use CMake to build Boost's documentation, which uses doxygen, docbook, xsltproc, Apache fop, etc., etc.)
Also the output directory for these tools should not contain the selected toolset's compiler name: http://article.gmane.org/gmane.comp.lib.boost.build/7276 (Maybe this has been corrected in current boost.build, but I'm guessing that a "typical" initial attempt to adapt CMake to boost's needs might suffer the same problem. )
* support for Boost's automatic linking feature. * Ability to define custom build variants, (eg., so I can build a library with FOO defined, and the resulting lib gets a different name.) * Easy to add tests: compile, run, link, compile-fail, link-fail
Also easy to just run part of the compiler (e.g. the preprocessor) and format the result (with e.g. indent) in order to ease debugging the preprocessor library. -thanks Larry
* It should be possible to build multiple variants of multiple targets with multiple compilers from a single build command.
This is the only one that jumped out as being out of order, however, having read the rest of the thread that followed I can say that one approach that works (at least for linux/win32) is that the CMake build step can actually generate scripts which can then be called from another script i.e. mainbuilddir ->compilerABuildDir (user runs cmake in here and builds boost with options A ->compilerBBuildDir (user runs cmake in here and builds boost with options B ..... and so on. The Top level Boost CMakeLists file can drop a file into mainbuilddir which contains instructions on how to cd compilerABuildDir call ctest/cpack/make docs etc cd compilerBBuildDir do the next etc. It may not know about CompilerC,D,E but by querying if dirX/KnownFile Exists it can automatically get going. In the case of CMake running multiple times with different options mainbuilddir will be scanned and altered on each pass. I've used an approach similar to this to generate scripts which automate testing etc so that even a complete numpty can simply call the script generated and everything is taken care of (this was before CTest became much better and does most of it for you now). JB PS. I am volunteering to assist CMakeifying Boost and can certainly devote a few man days or more to the job (though my Boost knowledge is a bit old as I stopped using it because it was a pain to keep installing on every machine...) -- John Biddiscombe, email:biddisco @ cscs.ch http://www.cscs.ch/about/BJohn.php CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
John Biddiscombe wrote:
* It should be possible to build multiple variants of multiple targets with multiple compilers from a single build command.
This is the only one that jumped out as being out of order, however, having read the rest of the thread that followed I can say that one approach that works (at least for linux/win32) is that the CMake build step can actually generate scripts which can then be called from another script
This actually isn't necessary. We've been using CMake for a number of years to build libraries and applications for multiple targets from the same source tree. Using CMake '-D' command line options allow variables to be set within CMake. A CMake file can also conditionally include other CMake file fragments. We use this to select cross compile toolsets, different support libraries, (etc). We actually have a directory structure similar to boost where object files are held in compile target specific sub-trees. This all works pretty well but there are a few CMake syntax convenience improvements that would be nice to have (e.g. case statements as well as if-then-else). -glenn
On May 9, 2007, at 12:05 PM, Eric Niebler wrote:
* Easy to add tests: compile, run, link, compile-fail, link-fail
I was just grepping through the Boost sources, and the only place I see link or link-fail tests is in tools/regression, where we're testing out the feature to make sure it works. Oh well. - Doug
Douglas Gregor wrote:
On May 9, 2007, at 12:05 PM, Eric Niebler wrote:
* Easy to add tests: compile, run, link, compile-fail, link-fail
I was just grepping through the Boost sources, and the only place I see link or link-fail tests is in tools/regression, where we're testing out the feature to make sure it works. Oh well.
You didn't look closely enough. :-) xpressive has a link test. I find it useful for catching problems like, "Oops, I forgot to make this function inline." -- Eric Niebler Boost Consulting www.boost-consulting.com
on Wed May 09 2007, Bill Hoffman <bill.hoffman-AT-kitware.com> wrote:
Hi,
I noticed the "boost development process / scope" thread on your list. A CMake user posted a link to your discussion. There is significant interest in the CMake community to help boost transition to CMake. Several people on the CMake list have volunteered to help, and Kitware is willing to put about 2 man weeks of effort into the conversion.
Whoa; that's a very significant development.
I think that CMake has all the features to do what you need at this point, but if any bugs or issues are discovered during the process, we can fix them and/or provide work-arounds for the issues.
I realize you have not yet decided on moving to CMake, but I thought I would put out this offer so that you could consider "free" support as one of the benefits you will receive from the port to CMake.
That's huge. I want to discuss our requirements, though, and make sure that they will actually be satisfied. One question on my mind: how much of what Boost.Build provides is already in the CMake system, and how much would have to be implemented on top of that, in CMake files? If there's a lot that would have to live outside of CMake itself, the value of a switch would be reduced. My main concern is that we satisfy most of http://www.boost.org/tools/build/v1/build_system.htm#design_criteria
I can see this happening in two ways. One would be for a CMake developer to create initial cmake files for boost, and get the basics working. Then, the work would be turned over to the Boost community. The other way would be to have a boost developer create the build files with help and support from the CMake community. Either way works for me. Of course, no one will want to do anything unless there is a commitment to actually use CMake.
Unfortunately I don't think Boost can commit to using CMake until we see that it can work for us. That would mean at least getting the basics working. Do we have a chicken-and-egg problem here? I for one am very grateful for the offer, and hope that we can take advantage of it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On May 9, 2007, at 12:35 PM, David Abrahams wrote:
on Wed May 09 2007, Bill Hoffman <bill.hoffman-AT-kitware.com> wrote:
I noticed the "boost development process / scope" thread on your list. A CMake user posted a link to your discussion. There is significant interest in the CMake community to help boost transition to CMake. Several people on the CMake list have volunteered to help, and Kitware is willing to put about 2 man weeks of effort into the conversion.
Whoa; that's a very significant development.
I think that CMake has all the features to do what you need at this point, but if any bugs or issues are discovered during the process, we can fix them and/or provide work-arounds for the issues.
I realize you have not yet decided on moving to CMake, but I thought I would put out this offer so that you could consider "free" support as one of the benefits you will receive from the port to CMake.
That's huge.
Yes, this is wonderful.
I want to discuss our requirements, though, and make sure that they will actually be satisfied. One question on my mind: how much of what Boost.Build provides is already in the CMake system, and how much would have to be implemented on top of that, in CMake files?
We'll have to build some of the more obscure things we do on top of CMake (e.g., the BoostBook toolchain) via its custom commands, of course.
If there's a lot that would have to live outside of CMake itself, the value of a switch would be reduced.
Yes and no. At least we'd be building on a well-documented core system, and the main important features of a build system---building and installing libraries---would be in the CMake core. Jam was a bit of a let-down because the base functionality is so weak (forcing us to re-build most of it in BBv1 and BBv2) and the Jam language itself is rather under-documented.
My main concern is that we satisfy most of http://www.boost.org/tools/build/v1/build_system.htm#design_criteria
The only one I'm not sure about is: - It should be possible to build multiple variants of multiple targets with multiple compilers from a single build command. I think this particular requirement is actually a problem itself: it only really helps Boost developers that want to quickly test on a couple of compilers. The majority of users will typically use Boost one just one compiler (especially those users picking up Boost for the first time, who are most put-off by a complicated build system). It's just as easy, if not easier, to keep separate build trees (one per compiler) rather than cram everything into a single build tree.
Unfortunately I don't think Boost can commit to using CMake until we see that it can work for us. That would mean at least getting the basics working. Do we have a chicken-and-egg problem here?
I for one am very grateful for the offer, and hope that we can take advantage of it.
I think someone from Boost needs try a proof-of-concept system with CMake before we ask for any assistance from Kitware. It does not make sense to ask a Kitware developer to write CMakeLists.txt files (the equivalent of our Jamfile.v2s) for all of the Boost libraries; that's better handled by someone familiar with BBv2 and familiar with the structure of Boost libraries. Of course, that means we need an intrepid volunteer to start converting Boost to CMake, and we'll see where we run into problems. Any takers? - Doug
Doug Gregor wrote:
The only one I'm not sure about is:
- It should be possible to build multiple variants of multiple targets with multiple compilers from a single build command.
I think this particular requirement is actually a problem itself: it only really helps Boost developers that want to quickly test on a couple of compilers. The majority of users will typically use Boost one just one compiler (especially those users picking up Boost for the first time, who are most put-off by a complicated build system). It's just as easy, if not easier, to keep separate build trees (one per compiler) rather than cram everything into a single build tree.
FWIW, I fully agree. This is a pure convenience that could easily be added on top by some simple canned command (or script). There is nothing in such a multi-build that would profit from a single command, no shared dependencies, etc., so there shouldn't be any reason to make that a requirement on the build system itself. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Doug Gregor wrote:
The only one I'm not sure about is:
- It should be possible to build multiple variants of multiple targets with multiple compilers from a single build command.
I think this particular requirement is actually a problem itself: it only really helps Boost developers that want to quickly test on a couple of compilers. The majority of users will typically use Boost one just one compiler (especially those users picking up Boost for the first time, who are most put-off by a complicated build system). It's just as easy, if not easier, to keep separate build trees (one per compiler) rather than cram everything into a single build tree.
FWIW, I fully agree. This is a pure convenience that could easily be added on top by some simple canned command (or script).
There is nothing in such a multi-build that would profit from a single command, no shared dependencies, etc., so there shouldn't be any reason to make that a requirement on the build system itself.
Having one tree per compiler will seriously break the regression test system, not to mention making it more resource intense for those that build/test several compilers on a machine. Not saying it can't be layered on, but I don't think having 3 trees to run 3 compilers is a good solution. Jeff
On May 9, 2007, at 2:50 PM, Jeff Garland wrote:
Having one tree per compiler will seriously break the regression test system, not to mention making it more resource intense for those that build/ test several compilers on a machine. Not saying it can't be layered on, but I don't think having 3 trees to run 3 compilers is a good solution.
What's wrong with having 3 *build* trees? We already do that with the regression test system, except that we call them bin.v2/compiler-1, bin.v2/compiler-2, and bin.v2/compiler-3 rather than compiler-1, compiler-2, and compiler-3. We'll still only have one source tree. - Doug
Doug Gregor wrote:
On May 9, 2007, at 2:50 PM, Jeff Garland wrote:
Having one tree per compiler will seriously break the regression test system, not to mention making it more resource intense for those that build/ test several compilers on a machine. Not saying it can't be layered on, but I don't think having 3 trees to run 3 compilers is a good solution.
What's wrong with having 3 *build* trees? We already do that with the regression test system, except that we call them bin.v2/compiler-1, bin.v2/compiler-2, and bin.v2/compiler-3 rather than compiler-1, compiler-2, and compiler-3.
We'll still only have one source tree.
Oh, that's fine - no problem with that. I mistook the comment to mean you'd need 3 source trees. Jeff
Jeff Garland wrote:
Having one tree per compiler will seriously break the regression test system, not to mention making it more resource intense for those that build/test several compilers on a machine. Not saying it can't be layered on, but I don't think having 3 trees to run 3 compilers is a good solution.
How does this layout require more resources ? There are no more object files in the suggested layout than are in the original one. (And what else would you put into the build tree ?) Yes, the regression test system would need some adjustments, but this is something that will be worked on anyway, I'd hope. ;-) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Jeff Garland wrote:
Having one tree per compiler will seriously break the regression test system, not to mention making it more resource intense for those that build/test several compilers on a machine. Not saying it can't be layered on, but I don't think having 3 trees to run 3 compilers is a good solution.
How does this layout require more resources ?
It doesn't...I misunderstood. See my reply to Doug. Jeff
on Wed May 09 2007, Doug Gregor <dgregor-AT-osl.iu.edu> wrote:
The only one I'm not sure about is:
- It should be possible to build multiple variants of multiple targets with multiple compilers from a single build command.
I think this particular requirement is actually a problem itself: it only really helps Boost developers that want to quickly test on a couple of compilers. The majority of users will typically use Boost one just one compiler (especially those users picking up Boost for the first time, who are most put-off by a complicated build system). It's just as easy, if not easier, to keep separate build trees (one per compiler) rather than cram everything into a single build tree.
I've been thinking the same thing myself for some time. However, for me, the ability to quickly test on a whole mess 'o' compilers has been crucial to my ability to build portable C++ libraries. So IMO it's still important to cover that use case somehow. Maybe that ends up being done with scripts? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On May 10, 2007, at 6:53 AM, David Abrahams wrote:
on Wed May 09 2007, Doug Gregor <dgregor-AT-osl.iu.edu> wrote:
The only one I'm not sure about is:
- It should be possible to build multiple variants of multiple targets with multiple compilers from a single build command.
I think this particular requirement is actually a problem itself: it only really helps Boost developers that want to quickly test on a couple of compilers. The majority of users will typically use Boost one just one compiler (especially those users picking up Boost for the first time, who are most put-off by a complicated build system). It's just as easy, if not easier, to keep separate build trees (one per compiler) rather than cram everything into a single build tree.
I've been thinking the same thing myself for some time.
However, for me, the ability to quickly test on a whole mess 'o' compilers has been crucial to my ability to build portable C++ libraries. So IMO it's still important to cover that use case somehow. Maybe that ends up being done with scripts?
I do this all of the time with autotools-based projects. I just have a set of build directories, and I run the same command in each one (which is trivial to script). I actually prefer this directory layout to having everything under bin.v2, because it's very easy to find (or remove) particular object files and executables for a certain compiler/platform (instead of digging in, e.g., bin.v2/libs/signals/ build/gcc-4.3.0_c++0x/debug/link-static/), and it's easier to parallelize the testing at a course granularity (since each configuration is distinct). My complaint with that requirement is that it has led to a design that makes the simple case (one system compiler) complicated. It's optimized for the more complicated cases that Boost developers need, but it's not clear to me that there's much benefit gained from this optimization over a simple top-level script. - Doug
On 05/09/2007 08:05 AM, Bill Hoffman wrote: [snip]
I will stay on this list while you decide, and answer any questions about CMake that may come up. Bill, one nice feature of boost build is that it allow selection of different toolsets with a toolset=ToolSetName. For example, toolset=gcc-4.3 or toolset=como. This creates different build directories with names composed from the toolset name to avoid mixing object files from different compilers. However, from a short read of:
http://cmake.org/HTML/RunningCMake.html which says: To build with just cmake change directory into where you want the binaries to be placed. which implies to me that the user would have to create those build directories himself and then specify in, I guess, a CMakeList.txt file, what compiler to use. Is that right? -thanks, Larry
Larry Evans wrote:
To build with just cmake change directory into where you want the binaries to be placed.
which implies to me that the user would have to create those build directories himself and then specify in, I guess, a CMakeList.txt file, what compiler to use.
Is that right?
FWIW, that's the typical GNU (autotools) build system procedure: You create a build directory, run $(srcdir)/configure from there, specifying any build options, and then 'make'. Thus, different build variants would all end up in distinct build directories, outside the source directory they were build from (and are dependent on). This approach is very natural for people working with autoconf / make. FWIW, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Larry Evans wrote:
To build with just cmake change directory into where you want the binaries to be placed.
which implies to me that the user would have to create those build directories himself and then specify in, I guess, a CMakeList.txt file, what compiler to use.
Is that right?
FWIW, that's the typical GNU (autotools) build system procedure: You create a build directory, run $(srcdir)/configure from there, specifying any build options, and then 'make'.
Thus, different build variants would all end up in distinct build directories, outside the source directory they were build from (and are dependent on).
This approach is very natural for people working with autoconf / make.
The problem with that approach is that it creates extra work that "users" must do to build. And any extra work the build system doesn't have control over raises the likelihood something will go wrong. For example, someone may forget that they need different dirs and accidentally reuse an existing one. Which could create all kinds of collisions and hard to diagnose errors. In the same sense that Boost.Build is written on top of Boost.Jam, it might make sense to treat cmake as a backend to a slim build description and control front end. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Stefan Seefeld wrote:
Thus, different build variants would all end up in distinct build directories, outside the source directory they were build from (and are dependent on).
This approach is very natural for people working with autoconf / make.
The problem with that approach is that it creates extra work that "users" must do to build. And any extra work the build system doesn't have control over raises the likelihood something will go wrong. For example, someone may forget that they need different dirs and accidentally reuse an existing one. Which could create all kinds of collisions and hard to diagnose errors.
Well, well, there are certainly mechanisms that could be put into place to help diagnose such errors (such as putting some timestamp / variant-stamp files into the build dir). Also, while it is certainly true that this requires more 'manual' intervention, as far as the build system itself is concerned, there is nothing preventing boost from adding a (tiny and un-intrusive) layer on top that makes sure those steps are enforced. However, this is a *much* better design as it reduces the scope of the build system, makes things more transparent, and enhances modularity (through a clearer separation of concern).
In the same sense that Boost.Build is written on top of Boost.Jam, it might make sense to treat cmake as a backend to a slim build description and control front end.
Right. I'm sure we can beat buildbot into shape for that, too. ;-) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On May 9, 2007, at 2:36 PM, Rene Rivera wrote:
Stefan Seefeld wrote:
FWIW, that's the typical GNU (autotools) build system procedure: You create a build directory, run $(srcdir)/configure from there, specifying any build options, and then 'make'.
Thus, different build variants would all end up in distinct build directories, outside the source directory they were build from (and are dependent on).
This approach is very natural for people working with autoconf / make.
The problem with that approach is that it creates extra work that "users" must do to build. And any extra work the build system doesn't have control over raises the likelihood something will go wrong. For example, someone may forget that they need different dirs and accidentally reuse an existing one. Which could create all kinds of collisions and hard to diagnose errors.
I wonder what percentage of Boost users actually configure more than one compiler with Boost.Build? And how many users actually use any compiler other than the one system compiler on their machines?
In the same sense that Boost.Build is written on top of Boost.Jam, it might make sense to treat cmake as a backend to a slim build description and control front end.
I strongly disagree with this approach, because it negates any of the positive effects of using an off-the-shelf build system. We expend a lot of effort maintaining Boost.Build, much of which could be avoided if we bought into an existing system rather than rolling our own. To switch to another "back-end" and still roll our own... that would just be more wasted effort. - Doug
On 05/09/2007 02:01 PM, Doug Gregor wrote: [snip]
I wonder what percentage of Boost users actually configure more than one compiler with Boost.Build? And how many users actually use any compiler other than the one system compiler on their machines?
Sometimes when I encounter a compile error with obscure error messages, it helps to get a 2nd opinion from another compiler. By looking at both compiler's error message, I can sometimes understand better what I did wrong. [snip]
Larry Evans wrote:
Sometimes when I encounter a compile error with obscure error messages, it helps to get a 2nd opinion from another compiler. By looking at both compiler's error message, I can sometimes understand better what I did wrong.
I also find it useful, been able to compile the module with different compilers, but I don't use boost build for it: I compile the module in question manually instead. This is to say, I don't think that "2nd opinion" necessiates executing boost build with several toolsets. Well, if you have a lot of modules you want a "2nd opinion" about, then, perhaps, it is worth it. Thanks, Boris ----- Original Message ----- From: "Larry Evans" <cppljevans@cox-internet.com> To: <boost@lists.boost.org> Sent: Wednesday, May 09, 2007 2:54 PM Subject: Re: [boost] Boost building with CMake
On 05/09/2007 02:01 PM, Doug Gregor wrote: [snip]
I wonder what percentage of Boost users actually configure more than one compiler with Boost.Build? And how many users actually use any compiler other than the one system compiler on their machines?
Sometimes when I encounter a compile error with obscure error messages, it helps to get a 2nd opinion from another compiler. By looking at both compiler's error message, I can sometimes understand better what I did wrong.
[snip]
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 5/9/07, Doug Gregor <dgregor@osl.iu.edu> wrote:
[snip]
I wonder what percentage of Boost users actually configure more than one compiler with Boost.Build? And how many users actually use any compiler other than the one system compiler on their machines?
I dont think it is very uncommon. Mainly if the user has a library-centric design.
[snip]
- Doug
-- Felipe Magno de Almeida
On May 9, 2007, at 3:07 PM, Felipe Magno de Almeida wrote:
On 5/9/07, Doug Gregor <dgregor@osl.iu.edu> wrote:
I wonder what percentage of Boost users actually configure more than one compiler with Boost.Build? And how many users actually use any compiler other than the one system compiler on their machines?
I dont think it is very uncommon.
Unfortunately, we have no data either way.
Mainly if the user has a library-centric design.
I'm quite certain that library developers aren't our main audience. Rather, I expect most Boost users are application developers. Most applications are only built on one compiler per platform, since you're not going to ship binaries built two compilers on the same platform. Skimming through the "Who's Using Boost?" pages, I'm seeing a bias toward applications. - Doug
On 5/9/07, Doug Gregor <dgregor@osl.iu.edu> wrote:
On May 9, 2007, at 3:07 PM, Felipe Magno de Almeida wrote:
[snip]
Unfortunately, we have no data either way.
Sure. So probably we shouldnt believe only, or almost so, boost developers would benefit from this.
Mainly if the user has a library-centric design.
I'm quite certain that library developers aren't our main audience. Rather, I expect most Boost users are application developers. Most applications are only built on one compiler per platform, since you're not going to ship binaries built two compilers on the same platform. Skimming through the "Who's Using Boost?" pages, I'm seeing a bias toward applications.
Most are applications. But that doesnt mean they dont write libraries to use with those applications. That's one kind of library-centric design for building applications. The project I work on is in "Who's Using Boost". Is called MIntercept and we have lots of libraries. The application is, practically, only the coordinator of these libraries. We test some libraries against two versions of VC++, and sometimes against cygwin too. It is very useful in C++ to have more than one compiler, and I believe boost users are very educated in these regards.
- Doug
Best regards, -- Felipe Magno de Almeida
Doug Gregor wrote:
I'm quite certain that library developers aren't our main audience. Rather, I expect most Boost users are application developers. Most applications are only built on one compiler per platform, since you're not going to ship binaries built two compilers on the same platform.
I use the same source tree (via NFS or other means) on several different machines. So, even if there's only one toolset to use per platform, it's still several toolsets per source tree. Regards, m
Martin Wille wrote:
Doug Gregor wrote:
I'm quite certain that library developers aren't our main audience. Rather, I expect most Boost users are application developers. Most applications are only built on one compiler per platform, since you're not going to ship binaries built two compilers on the same platform.
I use the same source tree (via NFS or other means) on several different machines. So, even if there's only one toolset to use per platform, it's still several toolsets per source tree.
I often work with several different compilers on the same machine with CMake and a single source tree. This is not a problem for CMake, you just have a separate build tree for each tool set used. -Bill
In article <074A0F51-7CA3-4B1A-B150-C5CC2866BA19@osl.iu.edu> DougGregor <dgregor@osl.iu.edu> wrote:
I wonder what percentage of Boost users actually configure more than one compiler with Boost.Build? And how many users actually use any compiler other than the one system compiler on their machines?
I can't give you a percentage but a lower bound for the absolute number. One. I used this feature extensively in application building. It's useful when switching compiler versions, or diagnosing compiler problems. Also having a second diagnostic for coding errors proved to be very useful. Thomas
Doug Gregor <dgregor@osl.iu.edu> writes:
I wonder what percentage of Boost users actually configure more than one compiler with Boost.Build? And how many users actually use any compiler other than the one system compiler on their machines?
If you like Boost, you use it, whatever compiler you have to use. On this machine, I use boost with Borland C++, various versions of MSVC, and gcc (mingw). Which compiler I use depends on the project I'm working on. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
on Wed May 09 2007, Doug Gregor <dgregor-AT-osl.iu.edu> wrote:
In the same sense that Boost.Build is written on top of Boost.Jam, it might make sense to treat cmake as a backend to a slim build description and control front end.
I strongly disagree with this approach, because it negates any of the positive effects of using an off-the-shelf build system.
We expend a lot of effort maintaining Boost.Build, much of which could be avoided if we bought into an existing system rather than rolling our own. To switch to another "back-end" and still roll our own... that would just be more wasted effort.
Well, c'mon. I am going to have to write scripts to quickly run developer tests on multiple compilers, and someone will have to make it possible for regression testers to do the same thing. Are you saying that code shouldn't be factored out and checked into Boost? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On May 10, 2007, at 7:01 AM, David Abrahams wrote:
on Wed May 09 2007, Doug Gregor <dgregor-AT-osl.iu.edu> wrote:
We expend a lot of effort maintaining Boost.Build, much of which could be avoided if we bought into an existing system rather than rolling our own. To switch to another "back-end" and still roll our own... that would just be more wasted effort.
Well, c'mon. I am going to have to write scripts to quickly run developer tests on multiple compilers, and someone will have to make it possible for regression testers to do the same thing. Are you saying that code shouldn't be factored out and checked into Boost?
Certainly not. Boost.Build version 2 is a very interesting, object- oriented build system built on top of Jam, that looks absolutely nothing like Jam. I don't see any point in building another build system on top of CMake that looks absolutely nothing like CMake. If we pick up a standard tool, let's use it as-is and only customize when we need to. - Doug
on Thu May 10 2007, Douglas Gregor <doug.gregor-AT-gmail.com> wrote:
On May 10, 2007, at 7:01 AM, David Abrahams wrote:
on Wed May 09 2007, Doug Gregor <dgregor-AT-osl.iu.edu> wrote:
We expend a lot of effort maintaining Boost.Build, much of which could be avoided if we bought into an existing system rather than rolling our own. To switch to another "back-end" and still roll our own... that would just be more wasted effort.
Well, c'mon. I am going to have to write scripts to quickly run developer tests on multiple compilers, and someone will have to make it possible for regression testers to do the same thing. Are you saying that code shouldn't be factored out and checked into Boost?
Certainly not.
You're not saying that, or code shouldn't be factored out?
Boost.Build version 2 is a very interesting, object- oriented build system built on top of Jam, that looks absolutely nothing like Jam. I don't see any point in building another build system on top of CMake that looks absolutely nothing like CMake. If we pick up a standard tool, let's use it as-is and only customize when we need to.
Sure. My point is that any kind of higher-level functionality we want to add, such as "multiple builds with one command," amounts to building a front-end, however thin. I think that's all Rene was saying. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On May 10, 2007, at 9:38 AM, David Abrahams wrote:
on Thu May 10 2007, Douglas Gregor <doug.gregor-AT-gmail.com> wrote:
On May 10, 2007, at 7:01 AM, David Abrahams wrote:
on Wed May 09 2007, Doug Gregor <dgregor-AT-osl.iu.edu> wrote:
We expend a lot of effort maintaining Boost.Build, much of which could be avoided if we bought into an existing system rather than rolling our own. To switch to another "back-end" and still roll our own... that would just be more wasted effort.
Well, c'mon. I am going to have to write scripts to quickly run developer tests on multiple compilers, and someone will have to make it possible for regression testers to do the same thing. Are you saying that code shouldn't be factored out and checked into Boost?
Certainly not.
You're not saying that, or code shouldn't be factored out?
Stupid... written... communication... I'm not saying that code shouldn't be factored out and checked into Boost. I am saying that code should be factored out, but not to the point where we've built our own un-CMake-like build system on top of CMake. - Doug
On 9 May 2007, at 21:01, Doug Gregor wrote:
I wonder what percentage of Boost users actually configure more than one compiler with Boost.Build? And how many users actually use any compiler other than the one system compiler on their machines?
I typically use 2 different compilers on most machines. Matthias
Doug Gregor wrote:
And how many users actually use any compiler other than the one system compiler on their machines?
FWIW, I virtually never use the system compiler. In fact, I'm under the impression it's not uncommon even to put the compiler into the same version control system as the product being built with it. Regards, m
Rene Rivera wrote:
Stefan Seefeld wrote:
FWIW, that's the typical GNU (autotools) build system procedure: You create a build directory, run $(srcdir)/configure from there, specifying any build options, and then 'make'.
Thus, different build variants would all end up in distinct build directories, outside the source directory they were build from (and are dependent on).
This approach is very natural for people working with autoconf / make.
The problem with that approach is that it creates extra work that "users" must do to build. And any extra work the build system doesn't have control over raises the likelihood something will go wrong. For example, someone may forget that they need different dirs and accidentally reuse an existing one. Which could create all kinds of collisions and hard to diagnose errors.
In the same sense that Boost.Build is written on top of Boost.Jam, it might make sense to treat cmake as a backend to a slim build description and control front end.
I see that I'm in a small minority (perhaps a container with size of 1) but this is one of the reasons that Boost.Build has made life easier for me. I have converted all of our internal builds to Boost.Build and am working with several clients doing the same. When you are building systems that are destined for multiple targets (compiler, OS, threading model and other variants) ... having the build system just handle and understand what to do without my intervention is a selling point. The fact that building a multi-threaded target understands it needs the multi-threaded library versions, where to get them, and how to build them if they aren't there has removed many makefile and build issues we ad in the past. I've started looking at the CMake docs and I'll need to wade through them some more.... and I know that I'm not a boost developer.... but the Boost.Build concepts of project and target usage-requirements paired with alias and the /project id//target syntax have made many build situations I encounter trivial to implement. Boost.Build was refreshing to me because it solved many of the multi-target issues I deal with daily. I suspect CMake has similar features. -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On 5/9/07, Michael Caisse <boost@objectmodelingdesigns.com> wrote:
[snip]
I see that I'm in a small minority (perhaps a container with size of 1) but this is one of the reasons that Boost.Build has made life easier for me. I have converted all of our internal builds to Boost.Build and am working with several clients doing the same.
Not at all, I'm with you.
When you are building systems that are destined for multiple targets (compiler, OS, threading model and other variants) ... having the build system just handle and understand what to do without my intervention is a selling point. The fact that building a multi-threaded target understands it needs the multi-threaded library versions, where to get them, and how to build them if they aren't there has removed many makefile and build issues we ad in the past.
Same for me. It seems boost.build is becoming a real burden on boost. I would really like to see boost developing great tools as it develops great libraries.
[snip]
--
---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
Best regards, -- Felipe Magno de Almeida
Felipe Magno de Almeida wrote:
It seems boost.build is becoming a real burden on boost. I would really like to see boost developing great tools as it develops great libraries.
Even after reading this over multiple times it sounds like two contradicting statements. Do you suggest boost to move on in the build tool business or not ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 5/9/07, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Felipe Magno de Almeida wrote:
It seems boost.build is becoming a real burden on boost. I would really like to see boost developing great tools as it develops great libraries.
Even after reading this over multiple times it sounds like two contradicting statements. Do you suggest boost to move on in the build tool business or not ?
Sorry, it really is contradicting. What I meant is that there seem to be a lot of interest in getting out of tool development in boost. But I really think we should continue developing those tools. And I think so because boost is really different from what is there outside. Boost.build seems to me as something unique. Sure, there are a lot of things that needs improvement, but the know-how boost has acquired in boost.build is quite big and I believe using this knowledge to improve bbv2 is better in the long term.
Thanks, Stefan
--
...ich hab' noch einen Koffer in Berlin...
Best regards, -- Felipe Magno de Almeida
Felipe Magno de Almeida wrote:
On 5/9/07, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Felipe Magno de Almeida wrote:
It seems boost.build is becoming a real burden on boost. I would really like to see boost developing great tools as it develops great libraries. Even after reading this over multiple times it sounds like two contradicting statements. Do you suggest boost to move on in the build tool business or not ?
Sorry, it really is contradicting. What I meant is that there seem to be a lot of interest in getting out of tool development in boost. But I really think we should continue developing those tools. And I think so because boost is really different from what is there outside. Boost.build seems to me as something unique. Sure, there are a lot of things that needs improvement, but the know-how boost has acquired in boost.build is quite big and I believe using this knowledge to improve bbv2 is better in the long term.
I don't quite agree. There are very few people who know boost.build (v2). Many less than people who understand other build systems. That's one of the reasons things are so fragile. Also, I can't say it often enough: I'm not arguing against any of these tools. They certainly have merit. But boost.org itself has a scope into which these tools don't fall, so I'd prefer them to be developed elsewhere, to keep people focused on "C++ libraries", as opposed to "things we can do better than the rest of the world". Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 5/9/07, Stefan Seefeld <seefeld@sympatico.ca> wrote:
[snip]
I don't quite agree. There are very few people who know boost.build (v2). Many less than people who understand other build systems. That's one of the reasons things are so fragile.
Also, I can't say it often enough: I'm not arguing against any of these tools. They certainly have merit. But boost.org itself has a scope into which these tools don't fall, so I'd prefer them to be developed elsewhere, to keep people focused on "C++ libraries", as opposed to "things we can do better than the rest of the world".
I understand. But I believe boost is not just "C++ libraries". IMO, what boost really do is improve C++. Through libraries, common use, and etc. That's how we see that C++ needs concepts, or how C++ needs decltype or auto. Anyway, I dont want Boost to start pursuing new goals just because it can, but it can, and have already, gone a lot farther than just C++ libraries.
Regards, Stefan
--
...ich hab' noch einen Koffer in Berlin...
Best regards, -- Felipe Magno de Almeida
Stefan Seefeld wrote:
Also, I can't say it often enough: I'm not arguing against any of these tools. They certainly have merit. But boost.org itself has a scope into which these tools don't fall, so I'd prefer them to be developed elsewhere, to keep people focused on "C++ libraries", as opposed to "things we can do better than the rest of the world".
I'm torn on this subject. Even though at some level I agree with you that Boost should be concentrating on the core library development. I also see that the Boost ideals, and the Boost community provides what AFAIK is a unique development structure. We are a group of developers that don't shy away from trying to implement the ideal in all areas. Having my roots in knowledge heavy AI fields, and content heavy game development, I recognize the essential nature of good development tools. So I'm afraid of what separating, or jettisoning, the tools we have. Which, I guess, raises the specter of forming a "Boost Tools" (sub)group. We might even be able to attract more tool developers in such a framework, as it would be attractive to more developers. Sorry to ramble... But thinking about this just brings up many issues in my head ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Sorry for the post... Looking at the web site/documentation I am unclear if the Yahoo jamboost group is still *live*. I have subscribed to the boost-build@lists.boost.org . Is there another place for me to go also if I want to get more involved? I've been looking at the trac tickets also. Thank you --- -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
Michael Caisse wrote:
Sorry for the post... Looking at the web site/documentation I am unclear if the Yahoo jamboost group is still *live*.
Hasn't been live for a long time now.
I have subscribed to the boost-build@lists.boost.org . Is there another place for me to go also if I want to get more involved? I've been looking at the trac tickets also.
That's the one list... Volodya, other BB interested people, and myself tend to frequent IRC also <irc://freenode/boost>. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
on Wed May 09 2007, Michael Caisse <boost-AT-objectmodelingdesigns.com> wrote:
Sorry for the post... Looking at the web site/documentation I am unclear if the Yahoo jamboost group is still *live*.
Where do you see that group mentioned in our docs? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
David Abrahams wrote:
on Wed May 09 2007, Michael Caisse <boost-AT-objectmodelingdesigns.com> wrote:
Sorry for the post... Looking at the web site/documentation I am unclear if the Yahoo jamboost group is still *live*.
Where do you see that group mentioned in our docs?
The first place was the "Feedback : [mailing list]" link here http://www.boost.org/tools/build/v2/index.html The second place I ran into it was while looking at discussion references in the Trac Tickets. I had some text file like hacking.txt that had it wrong... but when I grep for 'ahoo' I can't find where I got it. So, for now, the web page is the biggest offender. Regards - -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
I've been following the threads about building with boost and user experiences very carefully for the past couple months at least. Correct me if I am wrong... but the situation boils down to two items: o User Experience - first time users reaction out-of-the-tgz/zip o Library Author Experience - The ability for Boost library developers/testers to do what they need User Experience - I have read many people respond with the whole autoconfig familiarity for *nix developers. I would agree 100% 10 years ago, but today I think we are all trained to open the tar-ball and look for the INSTALL file to see what needs to be typed. To that end... I don't really care what I have to type, as long as it is installed on my machine. bjam was not installed on my machine, but I found a binary easily enough and was happy. The end result as a user... I had a "library" that I could include/link against using whatever build tool I was using. I also develop for win32 and several other targets and unlike *nix, there is no singular *norm* such as 'configure' or 'make install'. As such, I'm always having to look for the README file (or whatever the group decided to call it). As a win32 developer I was nearly ecstatic to find that I didn't have to load a VC project nor did I have to try getting the nmake file to work on my machine. I typed the bjam command as given in the documentation and it just worked... I was surprisingly shocked. All this to say... I don't care as a user how it builds as long as it is easy to do. Library Author Experience - All I can comment here is that I don't see a lot of complaints that bjam and Boost.Build don't do what people need. I see complaints that people have to learn another build tool or that the current tool is under-documented. Please correct me if I'm wrong, but my own experience for both library and application development (including writing custom generators) has been that the Boost.Build system is more than capable. I am sure this didn't come overnight and that there has been enormous thought and iteration to create such a system. So now that there is one... what is the effort to maintain it? As far as CMake... I suspect the above two considerations ultimately need to be measured. I clearly have no vote in this matter; however, it appears such a great effort has gone into creating a tool that works for the needs of the Boost community. I would hate to see great effort in switching if the source of the complaints are from a user group that would also have trouble getting Apache's Xerces-C going. Best Regards - -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On 09/05/07, Michael Caisse <boost@objectmodelingdesigns.com> wrote:
<snip>
All this to say... I don't care as a user how it builds as long as it is easy to do.
Yup. This brings up the point that there is no INSTALL file in the source tree. A link to the new getting started guide would make sense, IMHO. Library Author Experience -
All I can comment here is that I don't see a lot of complaints that bjam and Boost.Build don't do what people need. I see complaints that people have to learn another build tool or that the current tool is under-documented. Please correct me if I'm wrong, but my own experience for both library and application development (including writing custom generators) has been that the Boost.Build system is more than capable. I am sure this didn't come overnight and that there has been enormous thought and iteration to create such a system. So now that there is one... what is the effort to maintain it?
I can't help wondering how much of the apathy towards Boost.Build is borne out of the awkwardness of BBv1 and the countless support requests that came in regarding it. BBv2 is so much cleaner and Simply more intuitive than BBv1 that I (for one) hope it stays under development. If this CMake transition happens, I can only see it being forgotten about and fading into obscurity. I just hope BBv2 isn't skipped over too quickly before we assume there is as much resistance to it as there was to BBv1. Saying that - please correct me if I'm wrong - but a CMake transition, if it happened, doesn't sound like it would happen before 1.36. I suppose that means BBv2 at least has _some_ time to prove its worth. Darren
Darren Garvey wrote: <snip>
I can't help wondering how much of the apathy towards Boost.Build is borne out of the awkwardness of BBv1 and the countless support requests that came in regarding it. BBv2 is so much cleaner and Simply more intuitive than BBv1 that I (for one) hope it stays under development. If this CMake transition happens, I can only see it being forgotten about and fading into obscurity.
<snip> Perhaps that is why I don't see a problem. I've only used BBv2. -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
I'm confused as to what CMake actually does. Is it just a generator for various makefile/IDE projects from a common description? Does it do dependency tracking and incremental builds? Does it do MD5 summing? I gave a cursory glance at the website but didn't find my answers. For what I read in this thread it sounds like if I'm building my documentation it should spit out a vcproj which and then open and hit build on which then builds my quickbook application and all the libraries it depends on if they don't exist or aren't up to date and then runs quickbook to generate my boostbook xml then runs xlst-proc to generate my html documentation. I don't really understand how that is possible. Thanks, Michael Marcin
Michael Marcin wrote:
I'm confused as to what CMake actually does. Is it just a generator for various makefile/IDE projects from a common description? Does it do dependency tracking and incremental builds? Does it do MD5 summing? I gave a cursory glance at the website but didn't find my answers.
It does do dependency tracking if the native build system does not already do it.
For what I read in this thread it sounds like if I'm building my documentation it should spit out a vcproj which and then open and hit build on which then builds my quickbook application and all the libraries it depends on if they don't exist or aren't up to date and then runs quickbook to generate my boostbook xml then runs xlst-proc to generate my html documentation. I don't really understand how that is possible.
It is possible with custom commands in vcproj files. CMake abstracts custom commands so you can pretty much run any tool and produce any output you want. VTK and QT both use code generation. The code generators can be built and then run to create code that is then compiled. So, running executables to produce pretty much any output is possible from CMake, and works with VS IDE, nmake, make, Xcode, etc. -Bill
Bill Hoffman wrote:
Michael Marcin wrote:
I'm confused as to what CMake actually does. Is it just a generator for various makefile/IDE projects from a common description? Does it do dependency tracking and incremental builds? Does it do MD5 summing? I gave a cursory glance at the website but didn't find my answers.
It does do dependency tracking if the native build system does not already do it.
How does it compare speed wise with other solutions? Fast incremental builds are a very nice thing to have. There have been a few discussions on the sweng mailing list where CMake has been brought up and I don't think I ever saw performance reports for it. Generally the attitude there seems to be that Jam is best and KJam is better than that. How does CMake compare?
For what I read in this thread it sounds like if I'm building my documentation it should spit out a vcproj which and then open and hit build on which then builds my quickbook application and all the libraries it depends on if they don't exist or aren't up to date and then runs quickbook to generate my boostbook xml then runs xlst-proc to generate my html documentation. I don't really understand how that is possible.
It is possible with custom commands in vcproj files. CMake abstracts custom commands so you can pretty much run any tool and produce any output you want. VTK and QT both use code generation. The code generators can be built and then run to create code that is then compiled. So, running executables to produce pretty much any output is possible from CMake, and works with VS IDE, nmake, make, Xcode, etc.
I see. Thanks, Michael Marcin
Michael Marcin wrote:
How does it compare speed wise with other solutions? Fast incremental builds are a very nice thing to have. There have been a few discussions on the sweng mailing list where CMake has been brought up and I don't think I ever saw performance reports for it. Generally the attitude there seems to be that Jam is best and KJam is better than that. How does CMake compare?
The KDE folks and other projects have found CMake to be much faster than there previous build tools: "CMake searches for dependencies several times faster than the './configure' process did. CMake builds KDE 4's kdelibs about 40% faster than autotools build KDE 3.5.6's kdelibs, mostly due to a lack of libtool in the toolchain for CMake. The CMake toolchain (for UNIX) looks something like: cmake + make, whereas the autotools chain for KDE 3.5.6 looked something like: automake + autoconf + libtool + make + sh + perl + m4." http://dot.kde.org/1172083974/ http://mail.kde.org/pipermail/kde-buildsystem/2006-April/002232.html I am not sure how CMake compares to Jam. -Bill
on Wed May 09 2007, Michael Caisse <boost-AT-objectmodelingdesigns.com> wrote:
I would hate to see great effort in switching if the source of the complaints are from a user group that would also have trouble getting Apache's Xerces-C going. ^^^^^^^^^^^^^^^^^
I don't understnad the reference. Could you explain please? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
David Abrahams wrote:
on Wed May 09 2007, Michael Caisse <boost-AT-objectmodelingdesigns.com> wrote:
I would hate to see great effort in switching if the source of the complaints are from a user group that would also have trouble getting Apache's Xerces-C going.
^^^^^^^^^^^^^^^^^
I don't understnad the reference. Could you explain please?
I find that many people simply complain about having to build a library. If it doesn't just work from the installer... then some people I've worked with seem to think it is "hard". I've seen this with Xerces-C for example. There are perfectly good instructions for a variety of platforms on how to get it going. Each platform has it's own twist, but if you follow the directions and use your brain every-once-in-awhile you will have a library and some header files you can use. Using Xerces as an example (the use standard build tools)... in their bug database there are currently 73 active bugs for component 'Build'. There have been 409 issues since April 2004. These issues range the gambit of makefile dependency problems, installation copy issues, can't build with compiler make/model, link order, make clean 'degrees', and a variety of windows doesn't do make. Picking a different set of build tools does not eliminate problems... even if they are tools *everybody* knows. In this case it has opened up a whole set of build issues that Boost doesn't have: "My flavor of a build environment (make, nmake, VC project...) isn't working the way I think it should". I have had no problems at all building with BBv2 in my own projects (which include custom generators for home-grown code generators). I am encouraged to see organizations such as Sandia adopting BBv2 and suspect that if it is abandoned by Boost it will be picked up by another OpenSource team of developers. Eric Niebler and others have clearly articulated the requirements for a boost oriented build system; however, I haven't seen what problems are trying to be solved. The one issue continually reported is expending precious resources on build-tools. I personally don't think the problem goes away... it just shifts from something you control to supporting work-arounds for a host of other build systems. I've only been using BBv2 for a few months and just like I don't know the internals of gmake.... I don't know the internals of BBv2. This discussion has made me point emacs at jam-src and the *.jam files... who knows, perhaps someday I'll be able to contribute more than just a 'rant'. Sorry about the long post (0; Best Regards - -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
on Wed May 09 2007, "Felipe Magno de Almeida" <felipe.m.almeida-AT-gmail.com> wrote:
On 5/9/07, Michael Caisse <boost@objectmodelingdesigns.com> wrote:
[snip]
I see that I'm in a small minority (perhaps a container with size of 1) but this is one of the reasons that Boost.Build has made life easier for me. I have converted all of our internal builds to Boost.Build and am working with several clients doing the same.
Not at all, I'm with you.
When you are building systems that are destined for multiple targets (compiler, OS, threading model and other variants) ... having the build system just handle and understand what to do without my intervention is a selling point. The fact that building a multi-threaded target understands it needs the multi-threaded library versions, where to get them, and how to build them if they aren't there has removed many makefile and build issues we ad in the past.
Same for me.
It seems boost.build is becoming a real burden on boost. I would really like to see boost developing great tools as it develops great libraries.
I think Boost.Build has some great ideas (usage-requirements, anyone?), and should continue as a project in some form. However, build tools are definitely outside our core mission and Boost.Build is taking the resources of several people that could otherwise be making a much greater contribution to Boost, mostly because their regular Boost work depends on it (or because our users will need to understand how to do it and we worry about trying to document it). That's just not practical for Boost, IMO. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On May 9, 2007, at 2:20 PM, Stefan Seefeld wrote:
FWIW, that's the typical GNU (autotools) build system procedure: You create a build directory, run $(srcdir)/configure from there, specifying any build options, and then 'make'.
Thus, different build variants would all end up in distinct build directories, outside the source directory they were build from (and are dependent on).
This approach is very natural for people working with autoconf / make.
... and it works better for the CMake model, where one generates build rules for a specific environment (makefiles, VC++ solutions, XCode projects, etc.). - Doug
Doug Gregor wrote:
On May 9, 2007, at 2:20 PM, Stefan Seefeld wrote:
FWIW, that's the typical GNU (autotools) build system procedure: You create a build directory, run $(srcdir)/configure from there, specifying any build options, and then 'make'.
Thus, different build variants would all end up in distinct build directories, outside the source directory they were build from (and are dependent on).
This approach is very natural for people working with autoconf / make.
... and it works better for the CMake model, where one generates build rules for a specific environment (makefiles, VC++ solutions, XCode projects, etc.).
Speaking of that, another requirement: * Must be able to directly build, test, run commands, etc. without having to inject the generation of external build files into the process. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: Wednesday, May 09, 2007 11:54 AM To: boost@lists.boost.org Subject: Re: [boost] Boost building with CMake
Speaking of that, another requirement:
* Must be able to directly build, test, run commands, etc. without having to inject the generation of external build files into the process.
Actually I'm surprised that wasn't the first response to that email. Maybe CMake can directly build, but I haven't seen it. Sohail
Sohail Somani wrote:
* Must be able to directly build, test, run commands, etc. without having to inject the generation of external build files into the process.
Actually I'm surprised that wasn't the first response to that email. Maybe CMake can directly build, but I haven't seen it.
I'm not sure I understand the requirement. Are you saying the build system must not generate any intermediate files ? What do you mean by 'direct build' ? Why would you care at all about intermediate files ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld Sent: Wednesday, May 09, 2007 12:08 PM To: boost@lists.boost.org Subject: Re: [boost] Boost building with CMake
Sohail Somani wrote:
* Must be able to directly build, test, run commands, etc. without having to inject the generation of external build files into the process.
Actually I'm surprised that wasn't the first response to that email. Maybe CMake can directly build, but I haven't seen it.
I'm not sure I understand the requirement.
Are you saying the build system must not generate any intermediate files ? What do you mean by 'direct build' ? Why would you care at all about intermediate files ?
Not a Cmake guru, but as I understand it you have to configure the build via cmake files which then generates makefiles native for that platform. So that means for an x-platform developer, you have to use gnu/sun/aix/hp/make/visual studio which (imho) negates the whole point of an x-platform build tool. Of course, that is just my view and I like to use one tool well everywhere (preferably within my os emacs). Sohail
Sohail Somani wrote:
Not a Cmake guru, but as I understand it you have to configure the build via cmake files which then generates makefiles native for that platform.
So that means for an x-platform developer, you have to use gnu/sun/aix/hp/make/visual studio which (imho) negates the whole point of an x-platform build tool.
I don't agree. The point is not not to require native build tools, but to uniformize the build process (i.e. the part of it that users and developers have to care about). Whether that 'build system frontend' delegates to native tools is an entirely different question, as long as it gives the same platform coverage. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld Sent: Wednesday, May 09, 2007 12:31 PM To: boost@lists.boost.org Subject: Re: [boost] Boost building with CMake
Sohail Somani wrote:
Not a Cmake guru, but as I understand it you have to configure the build via cmake files which then generates makefiles native for that platform.
So that means for an x-platform developer, you have to use gnu/sun/aix/hp/make/visual studio which (imho) negates the whole point of an x-platform build tool.
I don't agree. The point is not not to require native build tools, but to uniformize the build process (i.e. the part of it that users and developers have to care about). Whether that 'build system frontend' delegates to native tools is an entirely different question, as long as it gives the same platform coverage.
True. Only that Cmake vanilla doesn't do this yet, though I can't imagine it would be hard to either write a wrapper or have Cmake modified to do it. Sohail
Stefan Seefeld wrote:
Sohail Somani wrote:
* Must be able to directly build, test, run commands, etc. without having to inject the generation of external build files into the process. Actually I'm surprised that wasn't the first response to that email. Maybe CMake can directly build, but I haven't seen it.
I'm not sure I understand the requirement.
Are you saying the build system must not generate any intermediate files ? What do you mean by 'direct build' ? Why would you care at all about intermediate files ?
I explain some aspect of that requirements in another email. But to answer you question directly :-) ... I don't care about intermediate files as such. What I care about is requiring to run *another* build/make/test executable/system/package to get from the build descriptions to the resulting target files, or test execution. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
on Wed May 09 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Stefan Seefeld wrote:
Sohail Somani wrote:
* Must be able to directly build, test, run commands, etc. without having to inject the generation of external build files into the process. Actually I'm surprised that wasn't the first response to that email. Maybe CMake can directly build, but I haven't seen it.
I'm not sure I understand the requirement.
Are you saying the build system must not generate any intermediate files ? What do you mean by 'direct build' ? Why would you care at all about intermediate files ?
I explain some aspect of that requirements in another email. But to answer you question directly :-) ...
I don't care about intermediate files as such. What I care about is requiring to run *another* build/make/test executable/system/package to get from the build descriptions to the resulting target files, or test execution.
Well we could of course always front-end-ize the process so it looks seamless. But why do you care so much?
From the POV of the edit/compile/debug cycle you can buy considerable speed by not doing some of the things we end up doing (auto-configuration, for example) every time you want to test a change.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On May 9, 2007, at 2:53 PM, Rene Rivera wrote:
Doug Gregor wrote:
On May 9, 2007, at 2:20 PM, Stefan Seefeld wrote:
FWIW, that's the typical GNU (autotools) build system procedure: You create a build directory, run $(srcdir)/configure from there, specifying any build options, and then 'make'.
Thus, different build variants would all end up in distinct build directories, outside the source directory they were build from (and are dependent on).
This approach is very natural for people working with autoconf / make.
... and it works better for the CMake model, where one generates build rules for a specific environment (makefiles, VC++ solutions, XCode projects, etc.).
Speaking of that, another requirement:
* Must be able to directly build, test, run commands, etc. without having to inject the generation of external build files into the process.
I don't understand this requirement. Are you saying that something like: configure make Does not meet the build-system requirements? - Doug
Doug Gregor wrote:
On May 9, 2007, at 2:53 PM, Rene Rivera wrote:
Doug Gregor wrote:
On May 9, 2007, at 2:20 PM, Stefan Seefeld wrote:
FWIW, that's the typical GNU (autotools) build system procedure: You create a build directory, run $(srcdir)/configure from there, specifying any build options, and then 'make'.
Thus, different build variants would all end up in distinct build directories, outside the source directory they were build from (and are dependent on).
This approach is very natural for people working with autoconf / make. ... and it works better for the CMake model, where one generates build rules for a specific environment (makefiles, VC++ solutions, XCode projects, etc.). Speaking of that, another requirement:
* Must be able to directly build, test, run commands, etc. without having to inject the generation of external build files into the process.
I don't understand this requirement. Are you saying that something like:
configure make
Does not meet the build-system requirements?
What I'm saying is that this doesn't meat the requirement: cd boost-root-nmake-vc80 cmake --use-nmake-vc80 ..\boost-root NMAKE NMAKE test NMAKE install cd boost-root-nmake-vc71 cmake --use-nmake-vc71 ..\boost-root NMAKE NMAKE test NMAKE install cd boost-root-gmake-gcc345 cmake --use-gmake-gcc345 ..\boost-root gmake gmake test gmake install Why should we give up the current: cd boost-root bjam msvc-8.0 test install bjam msvc-7.1 test install bjam gcc-3.4.5 test install (ignoring that those could be done in one command for comparison sake) ? The *only* benefit I see from using generation system like cmake, or wxWidget bakefile, is for end users where the Boost release manager creates a bunch of makefiles, nmake files, vc project files, etc. and hence the user doesn't have to use cmake, or bakefile. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
What I'm saying is that this doesn't meat the requirement:
cd boost-root-nmake-vc80 cmake --use-nmake-vc80 ..\boost-root NMAKE NMAKE test NMAKE install cd boost-root-nmake-vc71 cmake --use-nmake-vc71 ..\boost-root NMAKE NMAKE test NMAKE install cd boost-root-gmake-gcc345 cmake --use-gmake-gcc345 ..\boost-root gmake gmake test gmake install
Why should we give up the current:
cd boost-root bjam msvc-8.0 test install bjam msvc-7.1 test install bjam gcc-3.4.5 test install
(ignoring that those could be done in one command for comparison sake)
This can be easily added to cmake, and it can be done already with a ctest script similar to the ones we use to drive the dart clients. Something like: ctest -S boost.msvc-8.0.cmake ctest -S boost.msvc-7.1.cmake ctest -S boost.gcc-3.4.5.cmake (The code exists in cmake to drive all of the compilers and tool sets that cmake supports. This is used by ctest, and the try_compile/try_run code in CMake.)
The *only* benefit I see from using generation system like cmake, or wxWidget bakefile, is for end users where the Boost release manager creates a bunch of makefiles, nmake files, vc project files, etc. and hence the user doesn't have to use cmake, or bakefile
This, on the other hand, CMake does not do. Users are required to install cmake to be able to build. However, after installing and running CMake, users are able to use the build tool they are most familiar with. I am currently using gmake with the visual studio 2005 compiler, other people use nmake, others choose the vs IDE, Xcode and KDevelop are also supported. -Bill
On May 9, 2007, at 1:50 PM, Bill Hoffman wrote:
Rene Rivera wrote:
What I'm saying is that this doesn't meat the requirement:
This can be easily added to cmake, and it can be done already with a ctest script similar to the ones we use to drive the dart clients. Something like:
ctest -S boost.msvc-8.0.cmake ctest -S boost.msvc-7.1.cmake ctest -S boost.gcc-3.4.5.cmake
(The code exists in cmake to drive all of the compilers and tool sets that cmake supports.
Bill, Do you support the Pgi, Pathscale and Mipspro compilers? What is involved in bringing up cmake support for compilers you don't support? -- Noel
K. Noel Belcourt wrote:
Bill,
Do you support the Pgi, Pathscale and Mipspro compilers? What is involved in bringing up cmake support for compilers you don't support?
I know we can do Mipspro, and I think pgi has been done. It is not hard to add additional compilers. It involves creating a .cmake file that describes some flags and options for the compiler. -Bill
On May 9, 2007, at 2:23 PM, Bill Hoffman wrote:
K. Noel Belcourt wrote:
Bill,
Do you support the Pgi, Pathscale and Mipspro compilers? What is involved in bringing up cmake support for compilers you don't support?
I know we can do Mipspro, and I think pgi has been done. It is not hard to add additional compilers. It involves creating a .cmake file that describes some flags and options for the compiler.
Okay, I'll look over the .cmake files. A couple more questions if you don't mind. Is Cmake knowledgeable about, or is there built in support for, Mpi? Can you setup Cmake to build and link mixed languages, with mixed toolchains? For example, we need to build Fortran 77 and 90 with the Intel compiler, C and C++ with Gcc and link it all together into a single application with a C++ main (this is a key capability that we rely on with BBv2). Is this pretty easy to do with Cmake? Thanks. -- Noel
K. Noel Belcourt wrote:
Is Cmake knowledgeable about, or is there built in support for, Mpi?
Yes, ParaView uses CMake and MPI www.paraview.org.
Can you setup Cmake to build and link mixed languages, with mixed toolchains? For example, we need to build Fortran 77 and 90 with the Intel compiler, C and C++ with Gcc and link it all together into a single application with a C++ main (this is a key capability that we rely on with BBv2). Is this pretty easy to do with Cmake?
Yes, you can do mixed language builds and pick the linker language or let CMake pick on for you. -Bill
on Wed May 09 2007, Bill Hoffman <bill.hoffman-AT-kitware.com> wrote:
K. Noel Belcourt wrote:
Bill,
Do you support the Pgi, Pathscale and Mipspro compilers? What is involved in bringing up cmake support for compilers you don't support?
I know we can do Mipspro, and I think pgi has been done. It is not hard to add additional compilers. It involves creating a .cmake file that describes some flags and options for the compiler.
Boost.Build has "toolsets" that do something similar. However, really writing a good Boost.Build toolset involves much, much, more than that. Just look at tools/build/v2/tools/gcc.jam ... or tools/build/v2/tools/python.jam: there's a lot of code in there for supporting automatic toolset configuration. How much of that will we get from CMake? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
on Wed May 09 2007, Bill Hoffman <bill.hoffman-AT-kitware.com> wrote:
The *only* benefit I see from using generation system like cmake, or wxWidget bakefile, is for end users where the Boost release manager creates a bunch of makefiles, nmake files, vc project files, etc. and hence the user doesn't have to use cmake, or bakefile
This, on the other hand, CMake does not do. Users are required to install cmake to be able to build.
Really? That surprises me. Do the files generated by CMake encode specifics about the user's toolset locations and other things specific to the machine on which the builds are being performed? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
David Abrahams wrote:
on Wed May 09 2007, Bill Hoffman <bill.hoffman-AT-kitware.com> wrote:
Really? That surprises me.
Do the files generated by CMake encode specifics about the user's toolset locations and other things specific to the machine on which the builds are being performed?
For Makefiles, Cmake puts in rules to run itself to generate depend information. For all generators CMake puts in rules so that CMake will be re-run if one of its input files changes. Also, many shell like commands that are useful during the build process are provided by cmake. The install process is done by cmake. Basically, to be cross platform, you have to provide a bunch of functionality that is not provided by all platforms. In addition, CMake performs system introspection and finds installed libraries and header file locations for various packages, and that information is obviously not portable from machine to machine. It would be a much less full featured build set if you generated "movable" build files. However, CMake only requires a C++ compiler to build. So, if you are building a c++ project like Boost, then the native compiler and its tool chain are all that you need to build CMake. So, CMake does not require the user to install any thing beyond what they already have and the source to CMake. We do of course provide binaries for all major platforms. -Bill
In this discussion of CMake there has been no mention of how it fares in a cross-compiling environment. Can it be configured to build libraries for another type of system using a compiler capable of generating code for the non-native platform? Cheers, Brook
Brook Milligan wrote:
In this discussion of CMake there has been no mention of how it fares in a cross-compiling environment. Can it be configured to build libraries for another type of system using a compiler capable of generating code for the non-native platform?
Yes, CMake has been used for cross-compiling, and better support is on the way. We currently have a developer working full-time on making cross compiling a first-class feature. -Brad
On May 9, 2007, at 3:17 PM, Rene Rivera wrote:
Doug Gregor wrote: Why should we give up the current:
cd boost-root bjam msvc-8.0 test install bjam msvc-7.1 test install bjam gcc-3.4.5 test install
(ignoring that those could be done in one command for comparison sake)
Well, because it doesn't make the simple case simple. (1) Run CMake graphical configuration tool to generate makefiles/ projects/whatever (2) Load project into your favorite IDE (3) Hit "build" in your IDE CMake is about integrating well with the way the user develops code. That might be makefiles, VC++ projects, XCode projects, whatever. Having used CMake, bjam, and autotools, I've found CMake to be by far the easiest system for *users* to get up and running with. - Doug
Doug Gregor wrote:
On May 9, 2007, at 3:17 PM, Rene Rivera wrote:
Doug Gregor wrote: Why should we give up the current:
cd boost-root bjam msvc-8.0 test install bjam msvc-7.1 test install bjam gcc-3.4.5 test install
(ignoring that those could be done in one command for comparison sake)
Well, because it doesn't make the simple case simple.
(1) Run CMake graphical configuration tool to generate makefiles/ projects/whatever (2) Load project into your favorite IDE (3) Hit "build" in your IDE
CMake is about integrating well with the way the user develops code. That might be makefiles, VC++ projects, XCode projects, whatever. Having used CMake, bjam, and autotools, I've found CMake to be by far the easiest system for *users* to get up and running with.
Yes, but end-users are not the only audience we have to account for. Correct me if I'm wrong, but what you are saying is that: It is worth making Boost developers' life harder in order to make a particular subset of end-users life easier. Note: I happen to be one of the end-users of Boost.Build, so I avoid using IDEs, in particular VisualStudio, because they are some of the best examples of bad interface design (and I have yet to find an IDE that did not reduce programmer productivity). So in the discussions about switching build systems, I have to personally consider that I would stop helping in the maintenance of the build infrastructure for Boost. Which brings up the point, or maybe it was already mentioned, that any new technologies we consider, we have to consider the within Boost expertise available to maintain the new system. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On May 9, 2007, at 4:33 PM, Rene Rivera wrote:
Yes, but end-users are not the only audience we have to account for. Correct me if I'm wrong, but what you are saying is that: It is worth making Boost developers' life harder in order to make a particular subset of end-users life easier.
I didn't think I was making any trade-off. I want a build system that's easier for end users, especially first-time users. I don't see anything that makes it harder for developers.
Note: I happen to be one of the end-users of Boost.Build, so I avoid using IDEs, in particular VisualStudio, because they are some of the best examples of bad interface design (and I have yet to find an IDE that did not reduce programmer productivity).
Then don't use an IDE. CMake can generate the makefiles for you. Worse case, you need a top-level makefile to run multiple commands in one shot.
Which brings up the point, or maybe it was already mentioned, that any new technologies we consider, we have to consider the within Boost expertise available to maintain the new system.
Yes, definitely. The same consideration applies to Boost.Build version 2... how much expertise is there to maintain this system? As far as I know, only 2 people have any level of understanding of BBv2. I, personally, struggle to do anything that isn't copy-paste from something I've done earlier. Is there anyone outside of Boost that understands BBv2 at any level? - Doug
On May 9, 2007, at 3:39 PM, Doug Gregor wrote:
On May 9, 2007, at 4:33 PM, Rene Rivera wrote:
Which brings up the point, or maybe it was already mentioned, that any new technologies we consider, we have to consider the within Boost expertise available to maintain the new system.
Yes, definitely. The same consideration applies to Boost.Build version 2... how much expertise is there to maintain this system? As far as I know, only 2 people have any level of understanding of BBv2. I, personally, struggle to do anything that isn't copy-paste from something I've done earlier. Is there anyone outside of Boost that understands BBv2 at any level?
Hi Doug, Our organization has some experience with it. We recently adopted BBv2 as the primary development tool for the Sierra mechanics codes. As part of moving to BBv2, we jettisoned 37 build systems (36 third party build systems plus our own) and replaced them all with a single integrated build system, Boost Build. So while we definitely lack the experience of the primary developers, we found the transition to BBv2 easier than expected and it required only occasional help from the mailing list when we hit roadblocks. -- Noel
on Wed May 09 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Why should we give up the current:
cd boost-root bjam msvc-8.0 test install bjam msvc-7.1 test install bjam gcc-3.4.5 test install
A1: you shouldn't A2: because someone else will maintain and document the build tool for us? ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On 5/9/07, Doug Gregor <dgregor@osl.iu.edu> wrote:
On May 9, 2007, at 2:53 PM, Rene Rivera wrote:
[snip]
I don't understand this requirement. Are you saying that something like:
configure make
Does not meet the build-system requirements?
Seems very undesirable to me.
- Doug
Best regards, -- Felipe Magno de Almeida
Hello Bill, On Wed, 09 May 2007 09:05:30 -0400 Bill Hoffman <bill.hoffman@kitware.com> wrote:
Hi,
I noticed the "boost development process / scope" thread on your list. A CMake user posted a link to your discussion. There is significant interest in the CMake community to help boost transition to CMake. Several people on the CMake list have volunteered to help, and Kitware is willing to put about 2 man weeks of effort into the conversion. I think that CMake has all the features to do what you need at this point, but if any bugs or issues are discovered during the process, we can fix them and/or provide work-arounds for the issues.
I don't ever mean to look a gift-horse in the mouth so to speak, but I have reservations. Reservations that come from experience - we use VTK & ITK here, and many have inherited the CMake legacy into their own projects. I observe many just copy & paste slabs from CMakeLists.txt files, not really understanding what they are doing and getting it to work with trial & error. The recent backend changes to CMake posed a severe problem for some projects here, and the transition did not prove easy, with limited support on the web. Furthermore, in my experience I've found CMake to be overly complex. I've used & written build tools myself - multi-platform, using standard "standard" make, that are imminently more maintainable (, of course, it never did create vcproj files, but all our builds are done on the commandline - our windows users just use nmake instead with the build system, though admittedly windows users who liked the VC debugger were out of luck). Part of the problem with CMake I've found is that it allows you to build multiple executables in the one directory - this means having to specifically list dependencies, and with many executables for the one build file, it becomes a nightmare to maintain the primary CMake makefile. It doesn't encourage a clean separation of dependencies. If it didn't have this feature, it would be far simpler a tool. In short, CMake I have found tries to do too much, and as consequence (while it achieves its aims), obfuscates. With CMake you get multi-platform, but you also buy complexity - which shouldn't be part of the equation IMO.
I realize you have not yet decided on moving to CMake, but I thought I would put out this offer so that you could consider "free" support as one of the benefits you will receive from the port to CMake.
What does "free" mean here? Aide Boost in the transition to CMake, and after that we'd need to purchase the CMake manual - or log into some web forum on the kitware site to have our questions answered? The online information is at best useful for beginners, and the manual honestly doesn't fare much better.
I can see this happening in two ways. One would be for a CMake developer to create initial cmake files for boost, and get the basics working. Then, the work would be turned over to the Boost community. The other way would be to have a boost developer create the build files with help and support from the CMake community. Either way works for me. Of course, no one will want to do anything unless there is a commitment to actually use CMake.
I will stay on this list while you decide, and answer any questions about CMake that may come up.
Thanks, and I look forward to working with the boost community in the future.
I hope whatever way the wind blows, that if CMake is adopted by the Boost community, that my experiences and reservations will count amont the minority - ultimately we all want the best tools for Boost. This being said, I'd like to see BBv2 given a chance too. I sincerely apologize if I have come across as too negative, that's not the intention - it's more so perceptions bourne out of prior frustrations in using CMake. Cheers, -- Manfred Doudar - Research Engineer National ICT Australia - Canberra Research Lab | www.nicta.com.au Research School of Information Sciences and Engineering (RSISE) The Australian National University - Canberra, ACT 0200 AUSTRALIA
Manfred Doudar wrote:
Reservations that come from experience - we use VTK & ITK here, and many have inherited the CMake legacy into their own projects.
CMake was written for ITK, so ITK has been using CMake for 7 years since the start of ITK. VTK started using it about a year later. So both VTK and ITK suffer from getting around CMake features that were just not there in the start. BTW, CMake can still build very old versions of ITK and VTK, so we really do try for backwards compatibility. However, Boost would be getting a fresh start with a current CMake, and the cmake files should better organized than those of ITK or VTK at the end of the day.
I observe many just copy & paste slabs from CMakeLists.txt files, not really understanding what they are doing and getting it to work with trial & error.
That can happen with any program, and the support I am offering should help in avoiding that problem with Boost.
The recent backend changes to CMake posed a severe problem for some projects here, and the transition did not prove easy, with limited support on the web.
Sorry to hear you had trouble. Backwards compatibility is difficult, and we try hard, but sometimes miss. CMake went through a bunch of changes for KDE, and in much better shape for adoption by a new project today than it was a year ago. Also, there is still plenty of work to do, and CMake is being actively developed. The docs on the web have most of the information in the book, and all of the commands are documented right from the source code.
Furthermore, in my experience I've found CMake to be overly complex. I've used & written build tools myself - multi-platform, using standard "standard" make, that are imminently more maintainable (, of course, it never did create vcproj files, but all our builds are done on the commandline - our windows users just use nmake instead with the build system, though admittedly windows users who liked the VC debugger were out of luck).
CMake lets developers use the tools they are most productive with. Kitware's developers are about half make based and half IDE based. There are VS 7,8, Xcode, Kdevelop, nmake and make developers, and they are all happy with CMake. As with any software, the "source code" can become complicated. However, CMake does not require "complicated", and most of the "complicated" stuff should be hidden in the c++ core of CMake that generates the build files, and not in the users cmake input files.
Part of the problem with CMake I've found is that it allows you to build multiple executables in the one directory - this means having to specifically list dependencies, and with many executables for the one build file, it becomes a nightmare to maintain the primary CMake makefile. It doesn't encourage a clean separation of dependencies. If it didn't have this feature, it would be far simpler a tool.
I am not sure I follow the problem here. What dependencies do you have to list explicitly? The user just writes add_executable a few times, and it just works, there is no extra work to do by the end user.
In short, CMake I have found tries to do too much, and as consequence (while it achieves its aims), obfuscates. With CMake you get multi-platform, but you also buy complexity - which shouldn't be part of the equation IMO.
Many KDE folks would not agree with you, they say that they finally understand the build system as apposed to the one they had before. Here are some quotes: "By the KDE 3 series, there were only a select handful of elite build gurus who could understand the whole of KDE's build system." ... "Projects using CMake take less time to get started, since there is less time spent fighting with the build system. One KDE developer says, "CMake doesn't make you want to shoot yourself with a nailgun when building your project anymore." http://dot.kde.org/1172083974/
I realize you have not yet decided on moving to CMake, but I thought I would put out this offer so that you could consider "free" support as one of the benefits you will receive from the port to CMake.
What does "free" mean here? Aide Boost in the transition to CMake, and after that we'd need to purchase the CMake manual - or log into some web forum on the kitware site to have our questions answered? The online information is at best useful for beginners, and the manual honestly doesn't fare much better.
For this, I would like to refer to an outside opinion: "When I started to compare my notes from the first CMake-based projects I worked on, it became apparent that the book offers the same information that I also had access to -- it is more structured, and more comfy to consume leaning back with a cup of coffee, but the same basic content." http://www.kdedevelopers.org/node/2736 Documentation is a funny thing, the more you have of it, the less people read it. We could have phone books of the stuff and people would still say it is not documented well enough. I would also say that several non-Kitware CMake users from the CMake list have offered to help as well. And after the transition, I would imagine that I would stay on this list and answer questions when needed.
I sincerely apologize if I have come across as too negative, that's not the intention - it's more so perceptions bourne out of prior frustrations in using CMake.
No problem, you bring up valid points. My obviously biased opinion is that CMake will be good for Boost, as Boost will be good for CMake. :-) If Boost does not choose CMake today, or this year, well CMake will be around next year, and will be even better then. I personally feel that CMake is up to the job today. -Bill
Let me add my 2 cents on the topic. 1. I believe CMake proponents are simply kidding themselves. Changing boost make system with all it's unique and complicated requirements to anything else would require up to half a year of extensive development. Even based on existing facility. 2. I - as build system user - do not want to know ANYTHING about native build tools. I need single command that results in library compilation wherever I am on. 3. Do we (boost developers) really have any problems with BBv2? If more docs are required, wouldn't it be easier to write them instead of wasting time jumping from one build system to another? 4. What advantages does CMake have? I personally know nothing about it. That being said, I do like us to consider independent library versioning. And it does require support from make system. Does CMake could be ant help in this regard? Gennadiy. P.S. Another "but": I do not see any problems with having some developers to present .cmake file in their build directories so that CMake aware user's life is simplified.
on Wed May 09 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
Let me add my 2 cents on the topic.
1. I believe CMake proponents are simply kidding themselves. Changing boost make system with all it's unique and complicated requirements to anything else would require up to half a year of extensive development. Even based on existing facility.
Yeah, but someone else is volunteering to do the work, so the risk to us is minimal.
2. I - as build system user - do not want to know ANYTHING about native build tools. I need single command that results in library compilation wherever I am on.
Agreed. How is that relevant to the CMake question?
3. Do we (boost developers) really have any problems with BBv2?
Yes, I do. I started that project, so I have a vested interest in it. Still, I'm just about ready to stop sinking any more time into it. Just off the top of my head: - bjam appears to still be buggy - bjam consumes memory without bound (a design feature) - the build process part of bjam is inscrutable even to experts - only one person understands how to work on the core of BBv2 - the code is inscrutable and under-documented - that person is not writing documentation that would allow others to understand it - the language in which it is written is used in no other tool or project, thus presenting a barrier-to-entry for volunteers. - that person can't handle the volume of feature requests, help requests, and bug reports he gets. - there appear to be unresolvable philosophical differences about the design future of BBv2: http://tinyurl.com/34fqko
If more docs are required, wouldn't it be easier to write them instead of wasting time jumping from one build system to another?
Apparently only one person understands the system well enough to write them, but he is unable to keep up with the pace of development. I think maybe you can relate to that predicament ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
Hi, sorry for jumping in. Although I've used several build systems (in the sense of writing build scripts, e.g. make, ant, scons etc.) I have no experience with build script generators like CMake or MPC. Nevertheless I have reservations against them, see below. These may be prejudices and I'd be happy to be disabused.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Thursday, May 10, 2007 3:35 PM Subject: Re: [boost] Boost building with CMake
on Wed May 09 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
3. Do we (boost developers) really have any problems with BBv2?
Yes, I do. I started that project, so I have a vested interest in it. Still, I'm just about ready to stop sinking any more time into it. Just off the top of my head:
- the build process part of bjam is inscrutable even to experts - the language in which it is written is used in no other tool or project, thus presenting a barrier-to-entry for volunteers.
I'd expect that at least these two objections also apply to CMake. Both of them may be tolerable. What I have doubts about is the following. By using generated build scripts you leave the users (both library developers and end-users) with whatever more or less broken build tools their platforms happen to provide. As examples, I think some problems of make are well-known (see http://miller.emu.id.au/pmiller/books/rmch/) and I know from experience how horrible Visual Studios scales and misses dependencies. I'm also uncertain how users can be supported when they encounter problems with their build tool. Instead of a single build tool with a lot of compilers, you'd need expertise for a lot of build tools with another lot of compilers. You just multiply the problems (that might not be true for KDE, as I'd expect them to support fewer build tools, platforms and/or compilers than boost). The core business of build tools is dependency tracking and thus it might be unfair to compare CMake with build tools (rather than with autotools, MPC etc). To me the question is, if the build process shouldn't be optimised for a single, well-known build tool (not necessarily BBv2/bjam; I have problems myself, integrating it into our make-based build process, mainly because of the objections mentioned above). The two objections quoted above can be mitigated with tools like scons and rake (http://rake.rubyforge.org/). I know, scons has already been ruled out for whatever reasons, but perhaps rake is already there (I haven't used it yet)? cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | ames AT avaya DOT com Sitz der Gesellschaft: Stuttgart Registergericht: Amtsgericht Stuttgart - HRB 22107 Geschäftsführer: Andreas von Meyer zu Knonow, Udo Bühler, Thomas Kreikemeier
on Thu May 10 2007, "Ames, Andreas (Andreas)" <ames-AT-avaya.com> wrote:
boost-bounces@lists.boost.org wrote:
on Wed May 09 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
3. Do we (boost developers) really have any problems with BBv2?
Yes, I do. I started that project, so I have a vested interest in it. Still, I'm just about ready to stop sinking any more time into it. Just off the top of my head:
- the build process part of bjam is inscrutable even to experts - the language in which it is written is used in no other tool or project, thus presenting a barrier-to-entry for volunteers.
I'd expect that at least these two objections also apply to CMake.
Quite the opposite. CMake doesn't "do" build proceess: it delegates to lower-level tools like make or your IDE, and AFAIK, it's written in C++. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Thursday, May 10, 2007 9:07 PM To: boost@lists.boost.org Subject: Re: [boost] Boost building with CMake
Quite the opposite. CMake doesn't "do" build proceess: it delegates to lower-level tools like make or your IDE, and AFAIK, it's written in C++.
Sorry for being imprecise. You obviously meant the language in which CMake is written, I meant the language of the 'build scripts', which matters more to me as a user (at least I'd hope that). cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | ames AT avaya DOT com Sitz der Gesellschaft: Stuttgart Registergericht: Amtsgericht Stuttgart - HRB 22107 Geschäftsführer: Andreas von Meyer zu Knonow, Udo Bühler, Thomas Kreikemeier
on Thu May 10 2007, "Ames, Andreas (Andreas)" <ames-AT-avaya.com> wrote:
I know, scons has already been ruled out for whatever reasons
I don't think so. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87bqgsu7hn.fsf@grogan.peloton...
on Wed May 09 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
Let me add my 2 cents on the topic.
1. I believe CMake proponents are simply kidding themselves. Changing boost make system with all it's unique and complicated requirements to anything else would require up to half a year of extensive development. Even based on existing facility.
Yeah, but someone else is volunteering to do the work, so the risk to us is minimal.
I've got an impression that this someone do not really understand what he is getting into. Could anyone familiar with both BBv2 and CMake estimate amount of initilal efforts required? And most probably we will need ongoing support.
2. I - as build system user - do not want to know ANYTHING about native build tools. I need single command that results in library compilation wherever I am on.
Agreed. How is that relevant to the CMake question?
On cursory look on this discussion I've got an impression that CMake is native makefile generation system. IOW I will need to 1. run some kind of script to generate makefile 2. run native make command This is unacceptable for me on both counts. If we decide to build wrapper around CMake, who is going to develop and maintain it?
3. Do we (boost developers) really have any problems with BBv2?
Yes, I do. I started that project, so I have a vested interest in it. Still, I'm just about ready to stop sinking any more time into it. Just off the top of my head:
- bjam appears to still be buggy
In my personal expirience with BBv1, most of day to day activities worked fine. I never touched BBv2 yet.
- bjam consumes memory without bound (a design feature)
Do you mean it leaks memory?
- the build process part of bjam is inscrutable even to experts
Again. Couple times I had build bjam, I had no problems.
- only one person understands how to work on the core of BBv2
Ummm. How many do you think it should be? How many peoples know details of most boost libraries implementation?
- the code is inscrutable and under-documented
Which code you mean? My understanding is that we got application and scripts around it. Does implementation of any of Boost libraries is documented?
- that person is not writing documentation that would allow others to understand it
I remember there were several people volontiring to help with with making docs clear and "english friendly" ;)
- the language in which it is written is used in no other tool or project, thus presenting a barrier-to-entry for volunteers. - that person can't handle the volume of feature requests, help requests, and bug reports he gets. - there appear to be unresolvable philosophical differences about the design future of BBv2: http://tinyurl.com/34fqko
All in all the problems you are descripbing are real, but they primarily from development/support prospective, not usage.
If more docs are required, wouldn't it be easier to write them instead of wasting time jumping from one build system to another?
Apparently only one person understands the system well enough to write them, but he is unable to keep up with the pace of development. I think maybe you can relate to that predicament ;-)
Oh. Yes. This one hits close to home. But I still think working on docs is easier and more realistic than all around switch to the different make system. Gennadiy
Gennadiy Rozental wrote:
On cursory look on this discussion I've got an impression that CMake is native makefile generation system. IOW I will need to 1. run some kind of script to generate makefile 2. run native make command
This is unacceptable for me on both counts.
If we decide to build wrapper around CMake, who is going to develop and maintain it?
I think Cmake can maintain this. The functionality is already in CMake to run the various build tools supported via try_compile, and ctest. All that remains is to add a command line option to cmake. cmake --build-project So, it will become part of CMake, and we will maintain it. -Bill
on Thu May 10 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87bqgsu7hn.fsf@grogan.peloton...
on Wed May 09 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
Let me add my 2 cents on the topic.
1. I believe CMake proponents are simply kidding themselves. Changing boost make system with all it's unique and complicated requirements to anything else would require up to half a year of extensive development. Even based on existing facility.
Yeah, but someone else is volunteering to do the work, so the risk to us is minimal.
I've got an impression that this someone do not really understand what he is getting into.
That's his risk.
Could anyone familiar with both BBv2 and CMake estimate amount of initilal efforts required? And most probably we will need ongoing support.
Probably. I'd rather rely on a whole other open-source project with a company behind it for support, than on one guy who has another job to do.
2. I - as build system user - do not want to know ANYTHING about native build tools. I need single command that results in library compilation wherever I am on.
Agreed. How is that relevant to the CMake question?
On cursory look on this discussion I've got an impression that CMake is native makefile generation system. IOW I will need to 1. run some kind of script to generate makefile 2. run native make command
This is unacceptable for me on both counts.
If we decide to build wrapper around CMake, who is going to develop and maintain it?
I don't have answerse for this one.
3. Do we (boost developers) really have any problems with BBv2?
Yes, I do. I started that project, so I have a vested interest in it. Still, I'm just about ready to stop sinking any more time into it. Just off the top of my head:
- bjam appears to still be buggy
In my personal expirience with BBv1, most of day to day activities worked fine. I never touched BBv2 yet.
By "bjam" I mean the executable build system driver. You apparently haven't seen the many, many posts from windows users having trouble with inscrutable error messages each time bjam tries to launch a build command. I've forgotten the exact message, but AFAIK we keep tweaking things but still don't have a handle on the problem.
- bjam consumes memory without bound (a design feature)
Do you mean it leaks memory?
Sort of. It stores every string permanently in a hash table, so they're not exactly leaked, but the effect is similar for the user.
- the build process part of bjam is inscrutable even to experts
Again. Couple times I had build bjam, I had no problems.
I'm talking about the 'C' code in the bjam sources that deals with the dependency graph, etc.
- only one person understands how to work on the core of BBv2
Ummm. How many do you think it should be?
Ummm? It was always supposed to be a multi-person project. It certainly is too big a project to be handled entirely by one person.
How many peoples know details of most boost libraries implementation?
Irrelevant. All of Boost depends on BBv2 and Volodya doesn't have time to do all the work that needs to be done without making people wait.
- the code is inscrutable and under-documented
Which code you mean?
The .jam code.
My understanding is that we got application and scripts around it.
??
Does implementation of any of Boost libraries is documented?
Yes, several. I mean, there are comments that will allow someone to grasp what the code is doing, and they are reasonably complete and free of ambiguity.
- that person is not writing documentation that would allow others to understand it
I remember there were several people volontiring to help with with making docs clear and "english friendly" ;)
Yeah, I was one of them. Where did that lead?
- the language in which it is written is used in no other tool or project, thus presenting a barrier-to-entry for volunteers. - that person can't handle the volume of feature requests, help requests, and bug reports he gets. - there appear to be unresolvable philosophical differences about the design future of BBv2: http://tinyurl.com/34fqko
All in all the problems you are descripbing are real, but they primarily from development/support prospective, not usage.
Yes. My biggest argument is that Boost is having a hard time bearing the costs of this situation.
If more docs are required, wouldn't it be easier to write them instead of wasting time jumping from one build system to another?
Apparently only one person understands the system well enough to write them, but he is unable to keep up with the pace of development. I think maybe you can relate to that predicament ;-)
Oh. Yes. This one hits close to home. But I still think working on docs is easier and more realistic than all around switch to the different make system.
it doesn't matter that it's easier if nobody is going to actually do it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
David Abrahams wrote:
on Thu May 10 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
Yes. My biggest argument is that Boost is having a hard time bearing the costs of this situation.
Yes, as a release manager I can attest to that. Thomas -- Thomas Witt witt@acm.org
David Abrahams wrote:
- there appear to be unresolvable philosophical differences about the design future of BBv2: http://tinyurl.com/34fqko
Huh? "philosophical differences about design future" is not what this thread is about, it's merely about details of some particular feature. Was this a flame bait?
If more docs are required, wouldn't it be easier to write them instead of wasting time jumping from one build system to another?
Apparently only one person understands the system well enough to write them, but he is unable to keep up with the pace of development. I think maybe you can relate to that predicament ;-)
I think unless you have some secret knowledge of why that "one person" was less then usually active for a certain time period, and have some exclusive access to his plans for near future, the above is FUD. - Volodya
On Thu, 10 May 2007 20:11:44 +0400 Vladimir Prus <ghost@cs.msu.su> wrote:
Apparently only one person understands the system well enough to write them, but he is unable to keep up with the pace of development. I think maybe you can relate to that predicament ;-)
I think unless you have some secret knowledge of why that "one person" was less then usually active for a certain time period, and have some exclusive access to his plans for near future, the above is FUD.
I don't think David was saying anything bad about that "one person" but just that the amount of workload required is more than ANY "one person" can keep up with... because it is all on the shoulders of "one person." At least, I interpreted it that way...
on Thu May 10 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
David Abrahams wrote:
- there appear to be unresolvable philosophical differences about the design future of BBv2: http://tinyurl.com/34fqko
Huh? "philosophical differences about design future" is not what this thread is about, it's merely about details of some particular feature. Was this a flame bait?
If more docs are required, wouldn't it be easier to write them instead of wasting time jumping from one build system to another?
Apparently only one person understands the system well enough to write them, but he is unable to keep up with the pace of development. I think maybe you can relate to that predicament ;-)
I think unless you have some secret knowledge of why that "one person" was less then usually active for a certain time period, and have some exclusive access to his plans for near future, the above is FUD.
I don't understand what you're saying. Of course I can't know the future. I can only look at past experience, the pace of development, the unfulfilled desires of several people to improve BBv2, the difficulty I (one of the original designers) have every time I have to work with generators or other components below the toolset level, your avowals that you're "not good at documentation," etc. That evidence is what led me to say it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
David Abrahams wrote:
on Thu May 10 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
David Abrahams wrote:
- there appear to be unresolvable philosophical differences about the design future of BBv2: http://tinyurl.com/34fqko
Huh? "philosophical differences about design future" is not what this thread is about, it's merely about details of some particular feature. Was this a flame bait?
If more docs are required, wouldn't it be easier to write them instead of wasting time jumping from one build system to another?
Apparently only one person understands the system well enough to write them, but he is unable to keep up with the pace of development. I think maybe you can relate to that predicament ;-)
I think unless you have some secret knowledge of why that "one person" was less then usually active for a certain time period, and have some exclusive access to his plans for near future, the above is FUD.
I don't understand what you're saying.
I'm saying that while I was less active that I would like for a couple of months, I don't agree there were any serious problems before that, and I think all extrapolations you make, in particular that necessary doc improvements will never be made, are just your personal opinions, which you present as facts. - Volodya
on Thu May 10 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
David Abrahams wrote:
on Thu May 10 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
David Abrahams wrote:
Apparently only one person understands the system well enough to write them, but he is unable to keep up with the pace of development. I think maybe you can relate to that predicament ;-)
I think unless you have some secret knowledge of why that "one person" was less then usually active for a certain time period, and have some exclusive access to his plans for near future, the above is FUD.
I don't understand what you're saying.
I'm saying that while I was less active that I would like for a couple of months, I don't agree there were any serious problems before that, and I think all extrapolations you make, in particular that necessary doc improvements will never be made, are just your personal opinions, which you present as facts.
Of course they're just my informed opinions, since after all nobody can ever know the future. I am reasonably confident of them, so I make assertions. However, my opinions are not based on what I saw over any two months, but a much longer span of years. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
my 2p (about 4 cents) I use Boost Build to build a number of libraries and applications across Linux (2 versions) and Windows. For me the nice thing is I have one set of declarations about what to include in building libraries and applications. I edit these files or my source files and type a single command on both platforms to build in parallel (multiple jobs) of what I need. I use the same command on both platforms and don't have to think about how to do it on each platform. It supports building Qt4 applications, it executes all my tests, I even have it discovering and executing my test code automagically by using globing of directories (convention over configuration). I perform a lot of incremental building and need the build to start as soon as possible, so ideally I'd like cached dependency generation and for the first build command to start as soon as the system works out anything needs to be done. Ideally I'd like saving a file in my editor to start the build whether I changed a build script/file or a source code file - thats why I don't like 'configure; make; foo; bar' chains of execution unless they all support the incremental approach. I'm not saying boost build is perfect (it takes a long time to decide to do nothing compared to a previous make based solution) but it works cross platform and on balance that won out for me. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
Just my 2 cent testimonial... In January I moved a moderate-sized commercial project from Makefiles to CMake. I think I was more powerful after a week with CMake than after ten years with makefiles and autoconf. Build dependencies comes effortlessly (no more clumsy -MM hacks), VPATH builds are the norm, and unit tests are handled by design. Then we do the Windows port, and a few minor improvements to the CMakeList file to find dependencies and the whole shebang is building cross-platform under Visual Studio. Then we try out KDevelop, and a simple `cmake -G KDevelop3` provides us with project files with zero additional effort. We now have different developers simultaneously using KDevelop, using vim/make, and using MSVC++ on Windows, no problem. The real rough spots are documentation, and the lack of clear standard usage. CMake documentation is confusing. CMake has been a moving (improving) target during the past couple years. As a result, there seems to be a lot of conflicting documentation floating around. For the same reason, there are multiple deprecated ways to do anything, with no clear standard usage. The community can't even seem to agree whether CMake commands SHOULD BE UPPER or lower case. That said, CMake beats out any other build system I've used hands down.
"Braddock Gaskill" <braddock@braddock.com> wrote in message news:pan.2007.05.11.03.20.25.985698@braddock.com...
Just my 2 cent testimonial...
In January I moved a moderate-sized commercial project from Makefiles to CMake. I think I was more powerful after a week with CMake than after ten years with makefiles and autoconf. Build dependencies comes effortlessly (no more clumsy -MM hacks), VPATH builds are the norm, and unit tests are handled by design.
Could you please give more details about testing, since this is part boost will be interrested in for sure,
Then we do the Windows port, and a few minor improvements to the CMakeList file to find dependencies and the whole shebang is building cross-platform under Visual Studio. Then we try out KDevelop, and a simple `cmake -G KDevelop3` provides us with project files with zero additional effort. We now have
I did not get it from above statement Did Cmake build your project or just created "project file"?
different developers simultaneously using KDevelop, using vim/make, and using MSVC++ on Windows, no problem.
The real rough spots are documentation, and the lack of clear standard usage.
CMake documentation is confusing. CMake has been a moving (improving) target during the past couple years. As a result, there seems to be a lot of conflicting documentation floating around.
Hmm. We REALLY don't want to get into another "Build system as moving target" situation. Again. Gennadiy
On May 11, 2007, at 12:53 AM, Gennadiy Rozental wrote:
Then we do the Windows port, and a few minor improvements to the CMakeList file to find dependencies and the whole shebang is building cross-platform under Visual Studio. Then we try out KDevelop, and a simple `cmake -G KDevelop3` provides us with project files with zero additional effort. We now have
I did not get it from above statement
Did Cmake build your project or just created "project file"?
*Sigh*. This is basic CMake knowledge, and it's been said at least 10 times in this thread. CMake is a makefile generator. It generates makefiles/project files/solutions/whatever for your native build environment. Once you've configured CMake for a particular compiler/platform, you'll rarely need to directly run it again. Just run your normal build tool ("make", or "nmake", or hit F7, or whatever) and your project will build. If what's been said about the CMake model does not make sense to you, please go download it and try building a small project with it; you'll get much better insight than we can give you through e-mail.
CMake documentation is confusing. CMake has been a moving (improving) target during the past couple years. As a result, there seems to be a lot of conflicting documentation floating around.
Hmm. We REALLY don't want to get into another "Build system as moving target" situation. Again.
The CMake developers have put a lot of effort into maintaining backward compatibility. So, while the "best way" do to a particular thing changes as CMake evolves, the "old way" still continues to work. Remember, the opposite of a moving target is a stagnant target. We want the ongoing maintenance and improvements that CMake brings. - Doug
"Douglas Gregor" <doug.gregor@gmail.com> wrote in message news:B73C08B4-0308-4A07-8E72-5B533353E140@osl.iu.edu...
On May 11, 2007, at 12:53 AM, Gennadiy Rozental wrote:
Then we do the Windows port, and a few minor improvements to the CMakeList file to find dependencies and the whole shebang is building cross-platform under Visual Studio. Then we try out KDevelop, and a simple `cmake -G KDevelop3` provides us with project files with zero additional effort. We now have
I did not get it from above statement
Did Cmake build your project or just created "project file"?
*Sigh*. This is basic CMake knowledge, and it's been said at least 10 times in this thread. CMake is a makefile generator. It generates makefiles/project files/solutions/whatever for your native build environment.
Well, then I don't believe it's acceptable in this form. With more than dozen of different configurations to support I don't really looking favourable on learning all the native build tools.
Once you've configured CMake for a particular compiler/platform, you'll rarely need to directly run it again. Just run your normal build tool ("make", or "nmake", or hit F7, or whatever) and your project will build. If what's been said about the CMake model does not make sense to you, please go download it and try building a small project with it; you'll get much better insight than we can give you through e-mail.
Though I do understand why this design might be attractive, I don't think it's what boost should be moving to.
CMake documentation is confusing. CMake has been a moving (improving) target during the past couple years. As a result, there seems to be a lot of conflicting documentation floating around.
Hmm. We REALLY don't want to get into another "Build system as moving target" situation. Again.
The CMake developers have put a lot of effort into maintaining backward compatibility. So, while the "best way" do to a particular thing changes as CMake evolves, the "old way" still continues to work. Remember, the opposite of a moving target is a stagnant target. We want the ongoing maintenance and improvements that CMake brings.
Good. Don't forget to let them know ;). IMO We should deal with this as we do with any other submission. Someone needs to bring it up and we should review it and make a decision. Gennadiy
Gennadiy Rozental wrote:
IMO We should deal with this as we do with any other submission. Someone needs to bring it up and we should review it and make a decision.
This is not like any other library because it impacts _all_ libraries and _all_ testers etc. And although the discussion on Cmake on this list is generally interesting, we should avoid making the same mistake as a few years ago. Last time when we were looking for a build-system (and finally decided on Jam), (I believe David Abrahams) had suggested a python-based build-system. This was unacceptable to many because it would mean boost had a dependency on python. Nevertheless of all those who objected, little had to work on/with the build system later on while the python-approach-supporters later on were stuck with much more work because of the criticism on the-python-approach. If we discuss features that we think are lacking in Cmake, we should also look at which build-system _does_ offer those features, which build-system would be a serious alternative. toon
on Fri May 11 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
IMO We should deal with this as we do with any other submission. Someone needs to bring it up and we should review it and make a decision.
That's not a half-bad idea. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
on Thu May 10 2007, Braddock Gaskill <braddock-AT-braddock.com> wrote:
In January I moved a moderate-sized commercial project from Makefiles to CMake. I think I was more powerful after a week with CMake than after ten years with makefiles and autoconf. Build dependencies comes effortlessly (no more clumsy -MM hacks), VPATH builds are the norm, and unit tests are handled by design.
Then we do the Windows port, and a few minor improvements to the CMakeList file to find dependencies and the whole shebang is building cross-platform under Visual Studio. Then we try out KDevelop, and a simple `cmake -G KDevelop3` provides us with project files with zero additional effort. We now have different developers simultaneously using KDevelop, using vim/make, and using MSVC++ on Windows, no problem.
The real rough spots are documentation,
Oh, I don't like the sound of that! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
In January I moved a moderate-sized commercial project from Makefiles to CMake.
Thank you for the experience report. It's very valuable to us when assessing our options for Boost.
The real rough spots are documentation, and the lack of clear standard usage.
CMake documentation is confusing. CMake has been a moving (improving) target during the past couple years. As a result, there seems to be a lot of conflicting documentation floating around.
Did you rely on the online documentation, or did you also buy the book, "Mastering CMake"? - Doug
on Sat May 12 2007, "Douglas Gregor" <dgregor-AT-cs.indiana.edu> wrote:
In January I moved a moderate-sized commercial project from Makefiles to CMake.
Thank you for the experience report. It's very valuable to us when assessing our options for Boost.
The real rough spots are documentation, and the lack of clear standard usage.
CMake documentation is confusing. CMake has been a moving (improving) target during the past couple years. As a result, there seems to be a lot of conflicting documentation floating around.
Did you rely on the online documentation, or did you also buy the book, "Mastering CMake"?
According to what Bill Hoffman told me, part of the reason the docs are confusing is that the book is outdated. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
David Abrahams wrote:
on Sat May 12 2007, "Douglas Gregor" <dgregor-AT-cs.indiana.edu> wrote:
Did you rely on the online documentation, or did you also buy the book, "Mastering CMake"?
According to what Bill Hoffman told me, part of the reason the docs are confusing is that the book is outdated.
I don't think I said that... I certainly did not mean to say it... :-) There are a few things that have been updated since the book, and they are covered here: http://www.cmake.org/Wiki/CMake_FAQ#What_is_the_most_recent_version_covered_... -Bill
For whatever it's worth, I'd like to give my opinions about this issue. I've personally handled some serious projects with serious build configurations which border from the trivial to the bizarre. I have had the experience of trying to build/port an application between Windows and Linux more than once while I also try to write libraries that will build on either platform. I've tried to do this before with "just auto-make and friends" and Boost.Build (v2 mostly) and I all I can say is that the first time I tried BBv2 it's simple enough to understand and use. Now I haven't been using Boost (or developing for Boost (yet) for the matter) as long as others on the list have so I haven't experienced the pain of building BBv1 and then transitioning to BBv2. But I have been able to use BBv2 extensively in at least a couple of projects (two of which open source, and two of which not open source) and all I can say is that it's been a breeze to use. What I particularly like about BBv2 is how easy it seems to make a Jamfile.v2 from scratch and modify it according to your later requirements without the pain you usually deal with in the Make family of tools. Although I understand the apprehension of maintaining the Jam sources (in C most of it) and even the Boost.Build .jam files, I for one have seen the benefits of such a system as being part of Boost. I guess the thought of using something not-Boost maintained is brought about by the obvious hardships in maintaining .jam files in Boost.Build itself, and extending the tool chain as well as the mere maintenance of the code to fight fires and squash bugs that seem to be never ending. The apprehension I feel in adopting CMake is with the inertia and the investment a lot of people have put into (me included) understanding and using effectively not only the Boost library but the excellent build system that comes with it "for free". I think I won't be alone in saying that people who have been burnt by the sheer nightmare that is writing a Makefile and maintaining it (even with the autotools) welcome the breeze that is Boost.Build and Boost.Jam . I don't know if it might be the name "CMake" but anything (IMO) remotely related to Make just turns me and a lot of developers who've dealt with it before away. Now I guess it might be too much to ask, but what if we allow some CMake specific stuff into Boost -- I mean, just include the build files in there and not require the Boost library to restructure itself and/or the files if it would be possible -- and let the users choose whether to use Boost.Jam+Boost.Build or CMake when building Boost for their system, we might be doing everyone a service by providing viable alternatives. If someone wants to pick up the task of using CMake to build Boost and contribute that knowledge/effort into the library/project, then I don't see why we should abandon Boost.Build and Boost.Jam when people still seem to want to use it. It might be a naive question, but why can't we let these build-system specific files reside in the distribution and let users pick which one works for them? I'm positive we can make the CMake and Boost.Build stuff reside in the same distribution and not have to abandon one in favor of another. I for one wouldn't want to see Boost.Build or Boost.Jam deprecated because I've greatly benefited from these technologies greatly. I just wish I could help make them tools better, or at least help it be the tool that the community would like it to be. //Steps down from Soap Box So personally, I'd like to still stick with Boost.Build and Boost.Jam -- and hope we can articulate the requirements somehow and file tickets for them so people can actually pick up where others left off and improve Boost.Build and Boost.Jam for everyone's sake. That however doesn't mean I would reject a well-meant effort of putting in the CMake build instructions/files into the distribution just as long as BBv2 and Boost.Jam stay. I hope this makes sense. (If not, sorry for the noise). On 5/13/07, Bill Hoffman <bill.hoffman@kitware.com> wrote:
David Abrahams wrote:
on Sat May 12 2007, "Douglas Gregor" <dgregor-AT-cs.indiana.edu> wrote:
Did you rely on the online documentation, or did you also buy the book, "Mastering CMake"?
According to what Bill Hoffman told me, part of the reason the docs are confusing is that the book is outdated.
I don't think I said that... I certainly did not mean to say it... :-) There are a few things that have been updated since the book, and they are covered here:
http://www.cmake.org/Wiki/CMake_FAQ#What_is_the_most_recent_version_covered_...
-Bill
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459
Dean Michael Berris wrote:
For whatever it's worth, I'd like to give my opinions about this issue.
<snip>
What I particularly like about BBv2 is how easy it seems to make a Jamfile.v2 from scratch and modify it according to your later requirements without the pain you usually deal with in the Make family of tools. Although I understand the apprehension of maintaining the Jam sources (in C most of it) and even the Boost.Build .jam files, I for one have seen the benefits of such a system as being part of Boost.
I for one wouldn't want to see Boost.Build or Boost.Jam deprecated because I've greatly benefited from these technologies greatly.
<snip>
//Steps down from Soap Box
So personally, I'd like to still stick with Boost.Build and Boost.Jam ... <snip>
I'd just like to add my agreement with all these points. I feel great joy in being able to write with relative ease a single Jamfile that allows me to compile the same library on virtually every platform with the exact same command ("bjam"). This is saving me a *lot* of headaches. And it seems to be easy to extend the use of bjam to individual non-portable situations. For example, I can now build C++/CLI libraries using bjam as well. Having a single tool with a single consistent syntax that works across all platforms is an absolutely wonderful thing. Knuth understood this when he developed TeX, and we mathematicians have benefited enormously from this. Tools like Perl and Python have a similar advantage. (I do wish Boost Build v2 was built using Python.) I consider Boost Build v2 to have the same advantage. Deane
Deane Yang wrote:
I feel great joy in being able to write with relative ease a single Jamfile that allows me to compile the same library on virtually every platform with the exact same command ("bjam"). This is saving me a *lot* of headaches.
<snip> It's nice to see all the love for BBv2. When I suggested looking into a CMake-based build system for Boost, I didn't mean to suggest that we would orphan BBv2 or the users who have come to depend on it. There are lots of build systems out there, however, and BBv2 is just one. I was hoping (and still am!) that we can have a build system that integrates easily into lots of build environments, BBv2 included. Personally, I would like to see CMake extended so that it can generate jamfiles in addition to makefiles, vcproj files, etc.. That way we would not lose anything or anyone in the transition -- no user left behind. I have no idea how difficult this would be, though, or if it's even possible. As for building on every platform with the exact same command, we already have assurances from Bill Hoffman that CMake will be extended to support this. Instead of "bjam", it would be "cmake --build-project". -- Eric Niebler Boost Consulting www.boost-consulting.com
on Sun May 13 2007, Eric Niebler <eric-AT-boost-consulting.com> wrote:
Deane Yang wrote:
I feel great joy in being able to write with relative ease a single Jamfile that allows me to compile the same library on virtually every platform with the exact same command ("bjam"). This is saving me a *lot* of headaches.
<snip>
It's nice to see all the love for BBv2. When I suggested looking into a CMake-based build system for Boost, I didn't mean to suggest that we would orphan BBv2 or the users who have come to depend on it. There are lots of build systems out there, however, and BBv2 is just one. I was hoping (and still am!) that we can have a build system that integrates easily into lots of build environments, BBv2 included. Personally, I would like to see CMake extended so that it can generate jamfiles in addition to makefiles, vcproj files, etc.. That way we would not lose anything or anyone in the transition -- no user left behind. I have no idea how difficult this would be, though, or if it's even possible.
The problem is that CMake would obsolete much of the configuration logic in BBv2, and only uses its backend build system as an extremely low-level build engine. The Jamfiles you'd get out of it would lose all the nice abstraction that they currently have and would become much more like raw makefiles. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On Wed, 16 May 2007 11:02:09 -0600 David Abrahams <dave@boost-consulting.com> wrote:
The problem is that CMake would obsolete much of the configuration logic in BBv2, and only uses its backend build system as an extremely low-level build engine. The Jamfiles you'd get out of it would lose all the nice abstraction that they currently have and would become much more like raw makefiles.
Funny... from someone who is confortable with Makefiles, the abstraction is one of the things that makes Boost.Build so hard to digest. At least when I look at a makefile, I can figure out what is happening. Unless I have a good understanding of the abstraction (not necessarily the details, but at least what it is TRYING to do), wading through Boost.Build reminds me of my first affair with sendmail.
On May 13, 2007, at 12:00 PM, Dean Michael Berris wrote:
I think I won't be alone in saying that people who have been burnt by the sheer nightmare that is writing a Makefile and maintaining it (even with the autotools) welcome the breeze that is Boost.Build and Boost.Jam . I don't know if it might be the name "CMake" but anything (IMO) remotely related to Make just turns me and a lot of developers who've dealt with it before away.
CMake is a cross-platform makefile/project generator. Much of what you like about bjam and BBv2---the ability to specify platform- independent build rules, etc.---is also available in CMake.
It might be a naive question, but why can't we let these build-system specific files reside in the distribution and let users pick which one works for them? I'm positive we can make the CMake and Boost.Build stuff reside in the same distribution and not have to abandon one in favor of another.
Can we really maintain two separate build systems? And keep them synchronized? That has the potential to be far worse than the status quo.
So personally, I'd like to still stick with Boost.Build and Boost.Jam -- and hope we can articulate the requirements somehow and file tickets for them so people can actually pick up where others left off and improve Boost.Build and Boost.Jam for everyone's sake. That however doesn't mean I would reject a well-meant effort of putting in the CMake build instructions/files into the distribution just as long as BBv2 and Boost.Jam stay.
At this point, I don't think it makes sense for anyone to have made up their mind, given than so few people are familiar with CMake. - Doug
On 5/13/07, Douglas Gregor <doug.gregor@gmail.com> wrote:
On May 13, 2007, at 12:00 PM, Dean Michael Berris wrote:
I think I won't be alone in saying that people who have been burnt by the sheer nightmare that is writing a Makefile and maintaining it (even with the autotools) welcome the breeze that is Boost.Build and Boost.Jam . I don't know if it might be the name "CMake" but anything (IMO) remotely related to Make just turns me and a lot of developers who've dealt with it before away.
CMake is a cross-platform makefile/project generator. Much of what you like about bjam and BBv2---the ability to specify platform- independent build rules, etc.---is also available in CMake.
From the discussion and docs, it does appear that way. It might even seem more "powerful" and "capable" than BBv2. I guess what I really
like about Boost.Build is the simplicity of the Jamfile, how succinctly it can (at the trivial and usual case) express the intentions of the Jamfile author. The deviation from Make in terms of syntax and semantics is also a welcome change, because much of what's wrong with Make has been addressed by what's right in BBv2. Although admittedly, I haven't tried CMake yet -- but I don't see the need for it yet, now that BBv2 has already met my personal needs in my projects.
It might be a naive question, but why can't we let these build-system specific files reside in the distribution and let users pick which one works for them? I'm positive we can make the CMake and Boost.Build stuff reside in the same distribution and not have to abandon one in favor of another.
Can we really maintain two separate build systems? And keep them synchronized? That has the potential to be far worse than the status quo.
If the question is "who will maintain the CMake build configuration for Boost", I think the answer would be whoever has enough CMake experience. As for maintaining the BBv2 build files, I think the current people maintaining it (the library authors) could do whatever they are already doing. Requiring library authors to maintain two build system configurations would be too much to ask I think, but if the transition to CMake would be entertained -- even tried -- then the effort would have to be from those who can make it happen with the least resistance and disruption as possible. That way, we can evaluate both systems -- BBv2 and CMake -- as we go along. I believe we don't have to rush this now because especially like now IMO BBv2 is holding its own as far as the distribution build is concerned. Please correct me if I'm wrong in this assessment.
So personally, I'd like to still stick with Boost.Build and Boost.Jam -- and hope we can articulate the requirements somehow and file tickets for them so people can actually pick up where others left off and improve Boost.Build and Boost.Jam for everyone's sake. That however doesn't mean I would reject a well-meant effort of putting in the CMake build instructions/files into the distribution just as long as BBv2 and Boost.Jam stay.
At this point, I don't think it makes sense for anyone to have made up their mind, given than so few people are familiar with CMake.
You're probably right. FWIW, I'll try and take a look at CMake as well -- and try to gain as much working information/knowledge about it. But I'd guess you know how influential a phenomenon inertia is and with the amount of investment people have already made into learning and loving BBv2, I guess one could understand the upfront apprehension to change. -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459
CMake is a cross-platform makefile/project generator. Much of what you like about bjam and BBv2---the ability to specify platform- independent build rules, etc.---is also available in CMake.
I would like to cast a vote in favor of giving CMake serious consideration. I have used CMake to build the ITK and VTK libraries (as well as a few other miscellaneous projects) for several years now, and find it to be generally straightforward to use and tweak. My recent experience with BBv2 was less satisfying, although it does function as advertised once you tease out all the relevant details. As someone who uses OSX heavily, there are two features that I particularly appreciate about CMake : 1) it is essentially trivial to build Universal libraries (cross-compiled and linked into a fat binary) and 2) it is easy to export an XCode project file. Point 1) is relevant in the sense that it demonstrates the ability of CMake to seamlessly deal with cross-compilation and an additional post-link step to produce the dual-CPU binaries. While many of the developers in the Boost community are happy to use command line tools, in developing native OSX GUI applications or contributing to existing projects using XCode, this is suboptimal, making the ability to produce native project files a nice feature. To the best of my knowledge, there is one feature that neither Boost.Build nor CMake supports at present on OSX, which is the generation of self-contained OSX Frameworks rather than standard static/dynamic libraries. It would be very interesting to me, for academic as well as purely selfish reasons, to see how difficult it is to accomplish this with each of these build systems, and might be an illuminating test of the flexibility of those systems and the responsiveness of the communities supporting them. I would also like to second the points made about the Boost mission - while good tools are always valuable, Boost is meant to be a C++ library project, not a tools project. It seems that offloading the heavy lifting of maintenance and improvement of build tools to another project that has this as its primary mission is a better division of labor; I'm also sure that any such project would be happy to benefit from the experience and input of Boost.Build users and developers. $0.02 Matthias
Matthias Schabel wrote:
To the best of my knowledge, there is one feature that neither Boost.Build nor CMake supports at present on OSX, which is the generation of self-contained OSX Frameworks rather than standard static/dynamic libraries. It would be very interesting to me, for academic as well as purely selfish reasons, to see how difficult it is to accomplish this with each of these build systems, and might be an illuminating test of the flexibility of those systems and the responsiveness of the communities supporting them.
I am working on framework generation, and the start implementation is in CVS CMake right now. If you want to beta test what I have, you can send me an email off the list, and I can tell you how to try it. -Bill
Dean Michael Berris wrote:
For whatever it's worth, I'd like to give my opinions about this issue.
I've personally handled some serious projects with serious build configurations which border from the trivial to the bizarre. I have had the experience of trying to build/port an application between Windows and Linux more than once while I also try to write libraries that will build on either platform. I've tried to do this before with "just auto-make and friends" and Boost.Build (v2 mostly) and I all I can say is that the first time I tried BBv2 it's simple enough to understand and use.
[snip]
I for one wouldn't want to see Boost.Build or Boost.Jam deprecated because I've greatly benefited from these technologies greatly. I just wish I could help make them tools better, or at least help it be the tool that the community would like it to be.
+1 from here. I've been using Boost.Build on and off for the last couple of years, without becoming (and fortunately without having felt the need to become) an expert on the build system itself. Boost.Build, at least in its most basic usage, is most often a breeze to use and especially to maintain. The 'usage-requirements' feature is brilliant and I really don't want to imagine maintaining build trees without it. I also like the declarative and, IMHO, uncluttered syntax in Jamfiles. There are downsides to BB as with anything else; it is based on a pretty obscure but reasonably capable language (bjam) which isn't the easiest to learn. OTOH, much of Boost.Builds power probably comes from the build-oriented language base it stands on. Having Boost.Build available in another, more wide-spread scripting language such as Ruby - which also can be used for writing very declarative stuff - would be heaven. Another weak point is the documentation, and the fact that there's only one real expert that knows the system inside-out (apologies if I'm stepping on someone's toes here). Having said that, in one way I wouldn't care that much if CMake would be the preferred build-system for Boost, as long as it would only be possible to invoke a single command to build all the libraries for a specific platform/compiler. Personally, I could live without the capability to build with multiple compilers using a single command. What I am afraid of, is that Boost.Build development would loose much of its momentum if it would not be the system used for building the Boost libraries. The amount of feedback from Boost users that is used in getting Boost.Build to be _the_ build system for cross-platform C++ development is crucial to further refinement. Maintaining multiple build system configurations for Boost is unfortunately not a realistic option, IMHO. Even if Boost would switch to CMake, I would still continue to use Boost.Build in my cross-platform projects as long as someone is actively maintaining it. While I'm at that point (cross-platform) - does anyone know if CMake is available for OpenVMS? I'm well aware that Boost.Build isn't compatible with OpenVMS currently, but I also believe that porting the current system would not be impossible as most of the Jam stuff is VMS-capable. [snip]
So personally, I'd like to still stick with Boost.Build and Boost.Jam -- and hope we can articulate the requirements somehow and file tickets for them so people can actually pick up where others left off and improve Boost.Build and Boost.Jam for everyone's sake. That however doesn't mean I would reject a well-meant effort of putting in the CMake build instructions/files into the distribution just as long as BBv2 and Boost.Jam stay.
Again, +1 for sticking with Boost.Build and Boost.Jam. Better the devil you know ... But, to enable most people (including me) to be able to make a qualified judgement: Why not wait until the svn switch, make a complete "cmake" dev branch of Boost, and implement CMake-based building there to demonstrate proof of concept? Once that would be done, we would stand a really good chance to compare the two alternatives. Just my 0.02 EUR. / Johan
On May 16, 2007, at 12:01 AM, Johan Nilsson wrote:
But, to enable most people (including me) to be able to make a qualified judgement: Why not wait until the svn switch, make a complete "cmake" dev branch of Boost, and implement CMake-based building there to demonstrate proof of concept? Once that would be done, we would stand a really good chance to compare the two alternatives.
Troy Straszheim and I are building such a proof-of-concept based on a branch of Boost 1.34.0. We'll announce it to the list when we feel that it's ready. - Doug
On 05/16/2007 08:22 AM, Douglas Gregor wrote: [snip]
Troy Straszheim and I are building such a proof-of-concept based on a branch of Boost 1.34.0. We'll announce it to the list when we feel that it's ready.
Thanks, Troy and Doug. I've downloaded the sandbox-branches/boost-cmake/boost_1_34_0 yesterday. It's a great help to have some actual code to compare with the existing bjam code. However, I think the following comments: <------- cut here ---------- # Creates a new executable from source files. # # boost_add_executable(exename # source1 source2 ... # [COMPILE_FLAGS compileflags] # [feature_COMPILE_FLAGS compileflags] # [LINK_FLAGS linkflags] # [feature_LINK_FLAGS linkflags] # [LINK_LIBS linklibs] # [feature_LINK_LIBS linklibs] # [DEPENDS libdepend1 libdepend2 ...] # [feature] # [NO_INSTALL]) # ... # several cases, we use the placeholder "feature" in the option name # to indicate that there are actually several different kinds of # options, each referring to a different build feature ... # ... For a complete listing # of these features, please refer to the CMakeLists.txt file in the # root of the Boost distribution, which defines the set of features # that will be used to build Boost libraries by default.
------- cut here ----------
tools/build/CMake/BoostCore.cmake may need updating based on the ] following grep FLAGS output: <------- cut here ---------- cd /home/evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/boost_1_34_0/ grep FLAGS CMakeLists.txt Compilation exited abnormally with code 1 at Tue Aug 14 07:14:21
------- cut here ----------
I had expected to see some tokens ending with _LINK_FLAGS or _COMPILE_FLAGS corresponding to the feature_COMPILE_FLAGS and feature_LINK_FLAGS in the first part of the above comment. Of course we know you're still working on it, but I just didn't want this to be accidentally missed. Thanks again. -regards, Larry
On Tue, 2007-08-14 at 07:22 -0500, Larry Evans wrote:
tools/build/CMake/BoostCore.cmake may need updating based on the ] following grep FLAGS output:
<------- cut here ---------- cd /home/evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/boost_1_34_0/ grep FLAGS CMakeLists.txt
Compilation exited abnormally with code 1 at Tue Aug 14 07:14:21
------- cut here ----------
I had expected to see some tokens ending with _LINK_FLAGS or _COMPILE_FLAGS corresponding to the feature_COMPILE_FLAGS and feature_LINK_FLAGS in the first part of the above comment.
Well, you wouldn't actually find these based on "FLAGS". The features are all listed under the "Build Features and Variants" section in the top-level CMakeLists.txt. But, I would recommend not starting there: documentation for the CMake-based build system is on the Trac at http://svn.boost.org/trac/boost/wiki/CMake - Doug
On 08/14/2007 08:02 AM, Douglas Gregor wrote: [snip]
top-level CMakeLists.txt. But, I would recommend not starting there: documentation for the CMake-based build system is on the Trac at
Thanks. That's much better; however, I got an error: cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/build/ cmake ../src -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: CMAKE_CXX_COMPILER-NOTFOUND CMake Error: your CXX compiler: "CMAKE_CXX_COMPILER-NOTFOUND" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name. So, I edited the build/CMakeCache.txt: //CXX compiler. CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++-4.1 and the above command worked. Should the wiki/CMake mention the need to edit this CMakeCache.txt file or maybe some other file?
On 08/14/2007 11:03 AM, Larry Evans wrote:
On 08/14/2007 08:02 AM, Douglas Gregor wrote: [snip]
top-level CMakeLists.txt. But, I would recommend not starting there: documentation for the CMake-based build system is on the Trac at
[snip] So, I edited the build/CMakeCache.txt:
//CXX compiler. CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++-4.1
and the above command worked. [snip] In the build directory, there's an empty lib directory as well as a non-empty libs directory. I assume the lib directory creation is a bug; however, the wiki document:
http://svn.boost.org/trac/boost/wiki/CMakeConfigAndBuild does say lib instead of libs. Also that document uses the term "binary directory" to refer to the $(BOOST)/build directory. I'm wondering if it would be more readable to just say "build directory"?
On Aug 14, 2007, at 1:21 PM, Larry Evans wrote:
On 08/14/2007 11:03 AM, Larry Evans wrote:
On 08/14/2007 08:02 AM, Douglas Gregor wrote: [snip]
top-level CMakeLists.txt. But, I would recommend not starting there: documentation for the CMake-based build system is on the Trac at
[snip] So, I edited the build/CMakeCache.txt:
//CXX compiler. CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++-4.1
and the above command worked. [snip] In the build directory, there's an empty lib directory as well as a non-empty libs directory. I assume the lib directory creation is a bug; however, the wiki document:
http://svn.boost.org/trac/boost/wiki/CMakeConfigAndBuild
does say lib instead of libs.
"lib" will store all of the generated libraries, e.g., libboost_signals-1_34_0.so. It's the equivalent of stage/lib in BBv2.
Also that document uses the term "binary directory" to refer to the $(BOOST)/build directory. I'm wondering if it would be more readable to just say "build directory"?
Sure. I've updated the Trac page. - Doug
On Aug 14, 2007, at 12:03 PM, Larry Evans wrote:
On 08/14/2007 08:02 AM, Douglas Gregor wrote: [snip]
top-level CMakeLists.txt. But, I would recommend not starting there: documentation for the CMake-based build system is on the Trac at
Thanks. That's much better; however, I got an error:
cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/build/ cmake ../src -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: CMAKE_CXX_COMPILER-NOTFOUND CMake Error: your CXX compiler: "CMAKE_CXX_COMPILER-NOTFOUND" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
You don't have a C++ compiler in your path? Interesting.
So, I edited the build/CMakeCache.txt:
//CXX compiler. CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++-4.1
and the above command worked. Should the wiki/CMake mention the need to edit this CMakeCache.txt file or maybe some other file?
Or we could mention "ccmake". - Doug
On 08/14/2007 12:32 PM, Doug Gregor wrote:
On Aug 14, 2007, at 12:03 PM, Larry Evans wrote: [snip]
CMake Error: your CXX compiler: "CMAKE_CXX_COMPILER-NOTFOUND" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
You don't have a C++ compiler in your path? Interesting.
Yeah, I probably should. I *must* have had some reason for calling it g++-4.1 instead of just g++; however, I can't remember now. [snip]
and the above command worked. Should the wiki/CMake mention the need to edit this CMakeCache.txt file or maybe some other file?
Or we could mention "ccmake".
Sounds OK to me. [snip] Now, on another problem. I tried cd to the build/libs/mpl and noticed a Makefile but no test subdirectory; so I tried invoking make, but nothing was compiled. I guess this directory has not yet been converted to use CMake. Is there one that has so I could test it out? the src/libs/mpl/
On Aug 14, 2007, at 3:48 PM, Larry Evans wrote:
On 08/14/2007 12:32 PM, Doug Gregor wrote:
You don't have a C++ compiler in your path? Interesting.
Yeah, I probably should. I *must* have had some reason for calling it g++-4.1 instead of just g++; however, I can't remember now.
Okay. This is the kind of thing I wouldn't put on the introductory tutorial for getting Boost to build with CMake, because it's rather uncommon and would be clutter for most readers.
Now, on another problem. I tried cd to the build/libs/mpl and noticed a Makefile but no test subdirectory; so I tried invoking make, but nothing was compiled. I guess this directory has not yet been converted to use CMake. Is there one that has so I could test it out? the src/libs/mpl/
Most users don't want to run tests, so testing must be enabled manually. See: http://svn.boost.org/trac/boost/wiki/CMakeTesting - Doug
On 08/14/2007 03:02 PM, Doug Gregor wrote:
On Aug 14, 2007, at 3:48 PM, Larry Evans wrote:
On 08/14/2007 12:32 PM, Doug Gregor wrote:
You don't have a C++ compiler in your path? Interesting.
Yeah, I probably should. I *must* have had some reason for calling it g++-4.1 instead of just g++; however, I can't remember now.
Okay. This is the kind of thing I wouldn't put on the introductory tutorial for getting Boost to build with CMake, because it's rather uncommon and would be clutter for most readers.
Understandable.
Now, on another problem. I tried cd to the build/libs/mpl and noticed a Makefile but no test subdirectory; so I tried invoking make, but nothing was compiled. I guess this directory has not yet been converted to use CMake. Is there one that has so I could test it out? the src/libs/mpl/
Most users don't want to run tests, so testing must be enabled manually. See:
I tried just enabling the Metaprogramming test ( build/CMakeCache.txt contained: //Enable testing of Boost.Metaprogramming TEST_BOOST_METAPROGRAMMING:BOOL=ON ), then I did `make -i` (as suggested by wiki/CMakeTesting), then `ctest`; however, all tests failed: cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/build/ ctest Start processing tests Test project /home/evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/build 1/ 83 Testing metaprogramming::largest_int ***Failed 2/ 83 Testing metaprogramming::msvc_is_class***Failed 3/ 83 Testing metaprogramming::template_arit***Failed ... 82/ 83 Testing metaprogramming::vector_c ***Failed 83/ 83 Testing metaprogramming::zip_view ***Failed 0% tests passed, 83 tests failed out of 83 Doug, do you have any idea what I should do to get these tests to run? TIA. -regards, Larry
On 08/14/2007 04:38 PM, Larry Evans wrote:
On 08/14/2007 03:02 PM, Doug Gregor wrote:
On Aug 14, 2007, at 3:48 PM, Larry Evans wrote:
On 08/14/2007 12:32 PM, Doug Gregor wrote:
You don't have a C++ compiler in your path? Interesting.
Yeah, I probably should. I *must* have had some reason for calling it g++-4.1 instead of just g++; however, I can't remember now. Okay. This is the kind of thing I wouldn't put on the introductory tutorial for getting Boost to build with CMake, because it's rather uncommon and would be clutter for most readers.
Understandable.
Now, on another problem. I tried cd to the build/libs/mpl and noticed a Makefile but no test subdirectory; so I tried invoking make, but nothing was compiled. I guess this directory has not yet been converted to use CMake. Is there one that has so I could test it out? the src/libs/mpl/ Most users don't want to run tests, so testing must be enabled manually. See:
I tried just enabling the Metaprogramming test ( build/CMakeCache.txt contained:
//Enable testing of Boost.Metaprogramming TEST_BOOST_METAPROGRAMMING:BOOL=ON
), then I did `make -i` (as suggested by wiki/CMakeTesting), then `ctest`; however, all tests failed:
cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/build/ ctest Start processing tests Test project /home/evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/build 1/ 83 Testing metaprogramming::largest_int ***Failed 2/ 83 Testing metaprogramming::msvc_is_class***Failed 3/ 83 Testing metaprogramming::template_arit***Failed ... 82/ 83 Testing metaprogramming::vector_c ***Failed 83/ 83 Testing metaprogramming::zip_view ***Failed
0% tests passed, 83 tests failed out of 83
Doug, do you have any idea what I should do to get these tests to run?
Apparently ctest doesn't use the CMakeCache.txt because I just symlinked /usr/bin/g++ -> /usr/bin/g++-4.1 and ctest is now running the tests and they're passing.
On Aug 14, 2007, at 5:38 PM, Larry Evans wrote:
cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/build/ ctest Start processing tests Test project /home/evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/build 1/ 83 Testing metaprogramming::largest_int ***Failed 2/ 83 Testing metaprogramming::msvc_is_class***Failed 3/ 83 Testing metaprogramming::template_arit***Failed ... 82/ 83 Testing metaprogramming::vector_c ***Failed 83/ 83 Testing metaprogramming::zip_view ***Failed
0% tests passed, 83 tests failed out of 83
Doug, do you have any idea what I should do to get these tests to run?
I't s a bug in our build system. In particular, we're not passing the compiler through to the "CompileTest" projects used for compile-only tests. See, e.g., tools/build/CMake/CompileTest/CMakeLists.txt and tools/build/CMake/BoostTesting.cmake. Thanks for reporting this! Run-tests and run-fail tests should work fine. - Doug
On 08/15/2007 06:39 AM, Douglas Gregor wrote: [snip]
I't s a bug in our build system. In particular, we're not passing the compiler through to the "CompileTest" projects used for compile-only tests. See, e.g., tools/build/CMake/CompileTest/CMakeLists.txt and tools/build/CMake/BoostTesting.cmake. Thanks for reporting this! Sure.
Run-tests and run-fail tests should work fine.
Do you mean `ctest run-test` and `ctest run-fail`? On another matter. I'm wondering where the executables are placed. I found the .o files with find: cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/ find . -name \*.o ./build/tools/build/CMake/CompileTest/CMakeFiles/compile.dir/home/evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/src/libs/mpl/test/copy.o /build/tools/build/CMake/CompileTest/CMakeFiles/compile.dir/home/evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/src/libs/mpl/test/front.o However, I couldn't find the executables: cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/ find . ! -type d -perm /u+x |grep -v src ./dart-client/subprocess.py ./dart-client/client.py ./dart-client/conf.py Compilation finished at Wed Aug 15 07:10:24
On 08/15/2007 07:11 AM, Larry Evans wrote: [snip]
On another matter. I'm wondering where the executables are placed. I found the .o files with find:
cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/ find . -name \*.o ./build/tools/build/CMake/CompileTest/CMakeFiles/compile.dir/home/evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/src/libs/mpl/test/copy.o /build/tools/build/CMake/CompileTest/CMakeFiles/compile.dir/home/evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/src/libs/mpl/test/front.o
[snip] One other thing: The directory names shown by the output of find above don't indicate which compiler was used. Bjam does this so that different (and I assume incompatible ) compiler .o files won't be linked together. Is this on the todo list or is there some other way to emulate this bjam safety measure?
On Aug 15, 2007, at 8:17 AM, Larry Evans wrote:
One other thing: The directory names shown by the output of find above don't indicate which compiler was used. Bjam does this so that different (and I assume incompatible ) compiler .o files won't be linked together. Is this on the todo list or is there some other way to emulate this bjam safety measure?
The CMake-based system will not emulate this feature. If you want to build for multiple compilers, just create multiple build trees and configure/build them separately. - Doug
On 08/15/2007 07:49 AM, Doug Gregor wrote:
On Aug 15, 2007, at 8:17 AM, Larry Evans wrote:
One other thing: The directory names shown by the output of find above don't indicate which compiler was used. Bjam does this so that different (and I assume incompatible ) compiler .o files won't be linked together. Is this on the todo list or is there some other way to emulate this bjam safety measure?
The CMake-based system will not emulate this feature. If you want to build for multiple compilers, just create multiple build trees and configure/build them separately.
I tried this by creating a top-level build directory, built-by, with subdirectories: g++-4.1 #the "regular" compiler g++-4.3_v #the "variadic" compiler For 4.3_v, I had to first do `cmake <path-to-source>` then edit the g++-4.3_v/CMakeCache.txt to include the lines: //CXX compiler. CMAKE_CXX_COMPILER:FILEPATH=/home/evansl/download/gcc/variadic-templates/gcc-4.3-20070323/install/bin/g++ //Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING=-std=gnu++0x The FLAGS value was needed, as you know, to enable variadic templates. However, after I tried `make` the value of COMPILER:FILEPATH was reverted back to /usr/bin/g++ by something. How can that reversion be prevented or is there a better way to cause the variadic compiler to be used? -regards, Larry
Am Donnerstag, 16. August 2007 20:10:48 schrieb Larry Evans:
I tried this by creating a top-level build directory, built-by, with subdirectories:
g++-4.1 #the "regular" compiler g++-4.3_v #the "variadic" compiler
For 4.3_v, I had to first do `cmake <path-to-source>` then edit the g++-4.3_v/CMakeCache.txt to include the lines:
//CXX compiler. CMAKE_CXX_COMPILER:FILEPATH=/home/evansl/download/gcc/variadic-templates/gc c-4.3-20070323/install/bin/g++
//Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING=-std=gnu++0x
The FLAGS value was needed, as you know, to enable variadic templates.
However, after I tried `make` the value of COMPILER:FILEPATH was reverted back to /usr/bin/g++ by something. How can that reversion be prevented or is there a better way to cause the variadic compiler to be used?
Hello Larry, If you want to say CMake which compiler it has to use, you must give it via the matching environment variable (CXX for the c++ compiler, CC for c, FC for fortran) like: $ cd /path/to/builddir $ CXX=/home/evansl/download/gcc/variadic-templates\ /gcc-4.3-20070323/install/bin/g++ \ cmake /path/to/boost-cmake Note: you have to remove CMakeCache.txt, if it exists. This behavior of CMake ensures that the results of the test CMake runs on the compiler are allway valid. Since the results are stored in CMakeLists.txt, you have to remove it, which triggers CMake to rerun the compiler tests. Regards, Maik Beckmann
On 08/16/2007 01:42 PM, Maik Beckmann wrote:
Am Donnerstag, 16. August 2007 20:10:48 schrieb Larry Evans:
I tried this by creating a top-level build directory, built-by, with subdirectories:
g++-4.1 #the "regular" compiler g++-4.3_v #the "variadic" compiler
For 4.3_v, I had to first do `cmake <path-to-source>` then edit the g++-4.3_v/CMakeCache.txt to include the lines:
//CXX compiler. CMAKE_CXX_COMPILER:FILEPATH=/home/evansl/download/gcc/variadic-templates/gc c-4.3-20070323/install/bin/g++
//Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING=-std=gnu++0x
The FLAGS value was needed, as you know, to enable variadic templates.
However, after I tried `make` the value of COMPILER:FILEPATH was reverted back to /usr/bin/g++ by something. How can that reversion be prevented or is there a better way to cause the variadic compiler to be used?
Hello Larry,
If you want to say CMake which compiler it has to use, you must give it via the matching environment variable (CXX for the c++ compiler, CC for c, FC for fortran) like: $ cd /path/to/builddir $ CXX=/home/evansl/download/gcc/variadic-templates\ /gcc-4.3-20070323/install/bin/g++ \ cmake /path/to/boost-cmake
Or, a more descriptive name than /path/to/boost-cmake would be $BOOST/src, which is what's used on: http://svn.boost.org/trac/boost/wiki/CMakeConfigAndBuild
Note: you have to remove CMakeCache.txt, if it exists.
OK, so, in order to emulate Boost.Build's command line interface as close as possible, the user would create a bash (or whatever shell) file which has the one line: CXX=/home/evansl/download/gcc/variadic-templates\ /gcc-4.3-20070323/install/bin/g++ \ cmake $BOOST/src The only reason for this, which in this case is important, is to save repeatedly typing the long command between source code edits and testing. I assume the CMAKE_CXX_FLAGS:STRING value from the CMakeCache.txt is used since I saw the error message when make was run: Scanning dependencies of target boost_iostreams-shared [ 2%] Building CXX object libs/iostreams/src/CMakeFiles/boost_iostreams-shared.dir/file_descriptor.o cc1plus: error: unrecognized command line option "-std=gnu++0x" make[2]: *** [libs/iostreams/src/CMakeFiles/boost_iostreams-shared.dir/file_descriptor.o] This is inconsistent because the FLAGS value is used from CMakeCache.txt, but the CXX_COMPILER is ignored and even overwritten. Why put the CXX_COMPILER assignment in the CMakeCache.txt file if it's ignored?
This behavior of CMake ensures that the results of the test CMake runs on the compiler are allway valid. Since the results are stored in CMakeLists.txt,
Which CMakeLists.txt? The following command: cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/src/ find . -name CMakeLists.txt -ls 5181833 12 -rw-r--r-- 1 evansl evansl 10169 Aug 13 16:16 ./libs/config/test/CMakeLists.txt ... shows no times later than yesterday; hence, it's unclear to me what 'results are stored in CMakeLists.txt' means. Could you please clarify?
you have to remove it, which triggers CMake to rerun the compiler tests.
Does 'it' refer to CMakeLists.txt or CMakeCache.txt?
Regards, Maik Beckmann
Thanks for the feedback! -regards, Larry
Am Donnerstag, 16. August 2007 22:42:02 schrieb Larry Evans:
I assume the CMAKE_CXX_FLAGS:STRING value from the CMakeCache.txt is used since I saw the error message when make was run:
Scanning dependencies of target boost_iostreams-shared [ 2%] Building CXX object libs/iostreams/src/CMakeFiles/boost_iostreams-shared.dir/file_descriptor.o cc1plus: error: unrecognized command line option "-std=gnu++0x" make[2]: *** [libs/iostreams/src/CMakeFiles/boost_iostreams-shared.dir/file_descriptor.o ]
This means the compiler which was picked by CMake isn't aware of this option, so you should delete CMakeCache.txt and run CMake again with the right CXX.
This behavior of CMake ensures that the results of the test CMake runs on the compiler are allway valid. Since the results are stored in CMakeLists.txt,
Which CMakeLists.txt? The following command:
cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/src/ find . -name CMakeLists.txt -ls 5181833 12 -rw-r--r-- 1 evansl evansl 10169 Aug 13 16:16 ./libs/config/test/CMakeLists.txt ...
Argh, sorry for the confusion. This " results are stored in CMakeLists.txt " should be " results are stored in CMakeCache.txt " A CMakeLists.txt is allways written by the user, CMake only reads but never writes to them.
you have to remove it, which triggers CMake to rerun the compiler tests. Does 'it' refer to CMakeLists.txt or CMakeCache.txt? CMakeCache.txt!
Maik
Larry Evans wrote:
Note: you have to remove CMakeCache.txt, if it exists.
OK, so, in order to emulate Boost.Build's command line interface as close as possible, the user would create a bash (or whatever shell) file which has the one line:
CXX=/home/evansl/download/gcc/variadic-templates\ /gcc-4.3-20070323/install/bin/g++ \ cmake $BOOST/src
The only reason for this, which in this case is important, is to save repeatedly typing the long command between source code edits and testing. I assume the CMAKE_CXX_FLAGS:STRING value from the CMakeCache.txt is used since I saw the error message when make was run:
Scanning dependencies of target boost_iostreams-shared [ 2%] Building CXX object libs/iostreams/src/CMakeFiles/boost_iostreams-shared.dir/file_descriptor.o cc1plus: error: unrecognized command line option "-std=gnu++0x" make[2]: *** [libs/iostreams/src/CMakeFiles/boost_iostreams-shared.dir/file_descriptor.o]
This is inconsistent because the FLAGS value is used from CMakeCache.txt, but the CXX_COMPILER is ignored and even overwritten. Why put the CXX_COMPILER assignment in the CMakeCache.txt file if it's ignored?
It seems like there's a bit of a misunderstanding about the way CMake actual works that is causing a lot of confusion. The "cmake" program (and its more graphical cousin, "ccmake") generates makefiles. You should only need to run "cmake" or "ccmake" once, to configure your source tree. That execution creates the appropriate makefiles, and you use your normal platform build tool (say, "make") from there on. The only reason to re-run "cmake" is if you've changed options, by editing CMakeCache.txt directly. Personally, here's how I use CMake: I create a new build directory, and run "ccmake /path/to/boost" from that directory. In that interface, I set the options I'm interested in, (c)onfigure until they're stable, and (g)enerate makefiles. It is very, very, very rare that I actually need to run "cmake" or "ccmake" again after that, because calling "make" automatically keeps everything else in sync. - Doug
On 08/17/2007 07:47 AM, Douglas Gregor wrote:
Larry Evans wrote:
Note: you have to remove CMakeCache.txt, if it exists.
OK, so, in order to emulate Boost.Build's command line interface as close as possible, the user would create a bash (or whatever shell) file which has the one line:
CXX=/home/evansl/download/gcc/variadic-templates\ /gcc-4.3-20070323/install/bin/g++ \ cmake $BOOST/src
The only reason for this, which in this case is important, is to save repeatedly typing the long command between source code edits and testing. I assume the CMAKE_CXX_FLAGS:STRING value from the CMakeCache.txt is used since I saw the error message when make was run:
Scanning dependencies of target boost_iostreams-shared [ 2%] Building CXX object libs/iostreams/src/CMakeFiles/boost_iostreams-shared.dir/file_descriptor.o cc1plus: error: unrecognized command line option "-std=gnu++0x" make[2]: *** [libs/iostreams/src/CMakeFiles/boost_iostreams-shared.dir/file_descriptor.o]
This is inconsistent because the FLAGS value is used from CMakeCache.txt, but the CXX_COMPILER is ignored and even overwritten. Why put the CXX_COMPILER assignment in the CMakeCache.txt file if it's ignored?
It seems like there's a bit of a misunderstanding about the way CMake actual works that is causing a lot of confusion.
The "cmake" program (and its more graphical cousin, "ccmake") generates makefiles. You should only need to run "cmake" or "ccmake" once, to configure your source tree. That execution creates the appropriate makefiles, and you use your normal platform build tool (say, "make") from there on. The only reason to re-run "cmake" is if you've changed options, by editing CMakeCache.txt directly.
Doug, I did understand that cmake generates Makefiles; however, I thought editing the CMakeCache.txt file to change the compiler *then* running cmake would use the new compiler when generating the Makefile. But that's apparently wrong. Whenever I did that (edit CMakeCache.txt; run cmake) the CMakeCache.txt file value for the compiler was changed *back* to the value before the manual edit. As Maik indicated, the only way to get a new value for the compiler was with the command line invokation of cmake. The following shows the contents of the bash script file I used to do this: cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/built-by/g++-4.3_v/ cat CMake.sh #!/bin/bash CXX=/home/evansl/download/gcc/variadic-templates\ /gcc-4.3-20070323/install/bin/g++ \ cmake ../../src Compilation finished at Fri Aug 17 08:38:11 What's confusing is when ccmake is used and expert mode is turned on, the value for CMAKE_CXX_COMPILER is shown, but changing that, just like manually editing the CMakeCache.txt file to change it. has no effect. That's not very intuitive.
Personally, here's how I use CMake: I create a new build directory, and run "ccmake /path/to/boost" from that directory. In that interface, I set the options I'm interested in, (c)onfigure until they're stable, and (g)enerate makefiles. It is very, very, very rare that I actually need to run "cmake" or "ccmake" again after that, because calling "make" automatically keeps everything else in sync.
I tried that (at least I pretty sure that's what I did); yet, the CXX compiler was not retained when I ran cmake.
On Aug 15, 2007, at 8:11 AM, Larry Evans wrote:
On 08/15/2007 06:39 AM, Douglas Gregor wrote: [snip]
I't s a bug in our build system. In particular, we're not passing the compiler through to the "CompileTest" projects used for compile-only tests. See, e.g., tools/build/CMake/CompileTest/CMakeLists.txt and tools/build/CMake/BoostTesting.cmake. Thanks for reporting this! Sure.
Run-tests and run-fail tests should work fine.
Do you mean `ctest run-test` and `ctest run-fail`?
No, I mean tests that build actual executables and test whether they run correctly. For example, libs/function/test/function_test.cpp All of the MPL tests are compiled, but not executed. The Boost-CMake reference documentation on the Trac describes these different kinds of tests; the same test categories exist in BBv2.
On another matter. I'm wondering where the executables are placed. I found the .o files with find:
cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/ find . -name \*.o ./build/tools/build/CMake/CompileTest/CMakeFiles/compile.dir/home/ evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/src/libs/ mpl/test/copy.o /build/tools/build/CMake/CompileTest/CMakeFiles/compile.dir/home/ evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/src/libs/ mpl/test/front.o
However, I couldn't find the executables:
Because they don't exist. That's the point of the "compile" tests that MPL uses. BBv2 does the same thing (Boost.Build always has). - Doug
On 08/15/2007 06:39 AM, Douglas Gregor wrote:
On Aug 14, 2007, at 5:38 PM, Larry Evans wrote:
cd ~/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/build/ ctest Start processing tests Test project /home/evansl/prog_dev/boost-svn/ro/sandbox-branches/boost-cmake/build 1/ 83 Testing metaprogramming::largest_int ***Failed 2/ 83 Testing metaprogramming::msvc_is_class***Failed 3/ 83 Testing metaprogramming::template_arit***Failed ... 82/ 83 Testing metaprogramming::vector_c ***Failed 83/ 83 Testing metaprogramming::zip_view ***Failed
0% tests passed, 83 tests failed out of 83
Doug, do you have any idea what I should do to get these tests to run?
I't s a bug in our build system. In particular, we're not passing the [snip] The CMakeCache.txt contains the lines:
//Enable testing of Boost.IOStreams TEST_BOOST_IOSTREAMS:BOOL=ON I tried running just make instead of ctest to see if it would run the test; however, I got an error about missing static library (I've forgotten what library, but say it's XXX). So, I next entered ccmake to specify the build and test of XXX and then make. Then, after a few compiles, it said I was missing library YYY (where YYY is actually some real library name). The actual error message was along the pattern of: Linking CXX executable ../../bin/quickbook /usr/bin/ld: cannot find -lboost_filesystem-static collect2: ld returned 1 exit status What can be done so cmake generates the Makefiles which build the required libraries instead of complaining about not finding them? TIA. -regards, Larry
On 08/16/2007 08:11 AM, Larry Evans wrote: [snip]
The CMakeCache.txt contains the lines:
//Enable testing of Boost.IOStreams TEST_BOOST_IOSTREAMS:BOOL=ON
I tried running just make instead of ctest to see if it would run the test; however, I got an error about missing static library [snip] I just turned all the options to "ON" and ran make. No tests were run. I reread:
http://svn.boost.org/trac/boost/wiki/CMakeTesting which, of course, clearly implied the ctest had to be used to run the test; so, I ran: ctest -R iostreams:: and, like the doc says, just ran the iostreams tests. Sorry (again) for noise.
On 08/16/2007 09:58 AM, Larry Evans wrote:
On 08/16/2007 08:11 AM, Larry Evans wrote: [snip] I just turned all the options to "ON" and ran make. No tests were run. I reread:
http://svn.boost.org/trac/boost/wiki/CMakeTesting
which, of course, clearly implied the ctest had to be used to run the
The following comments: # makefiles. Use "make" to build, "make test" to test, "make # # install" to install, and "make package" to build binary # in the top-level CMakeLists.txt indicate that last conclusion about having to run ctest is wrong. I tried `make test` and the output, indeed, showed test drivers were being compiled. However, I had done a `make clean` and turned every BUILD_BOOST_library option in CMakeCache.txt OFF. Now, as reported previously, it's not finding the libraries. At first, it couldn't find the unit_test_framework library: [ 5%] Built target boost_iostreams-shared Linking CXX executable ../../../bin/tests/iostreams/array_test /usr/bin/ld: cannot find -lboost_unit_test_framework-shared collect2: ld returned 1 exit status However, after turning that ON, I got: /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crt1.o: In function `_start': ../sysdeps/i386/elf/start.S:115: undefined reference to `main' collect2: ld returned 1 exit status So then I tried: BUILD_STATIC:BOOL=ON and this got further: Linking CXX executable ../../../bin/tests/iostreams/regex_filter_test /usr/bin/ld: cannot find -lboost_regex-static collect2: ld returned 1 exit status make[2]: *** [bin/tests/iostreams/regex_filter_test] Error 1 make[1]: *** [libs/iostreams/test/CMakeFiles/regex_filter_test.dir/all] Error 2 make: *** [all] Error 2 So I looked at the iostreams test/Jamfile.v2 which showed regex_filter_test requiring boost_regex: [ test-iostreams regex_filter_test.cpp /boost/regex//boost_regex ] The corresponding line in iostreams test/CMakeLists.txt has: boost_test_run(regex_filter_test DEPENDS boost_unit_test_framework boost_regex COMPILE_FLAGS "-DBOOST_IOSTREAMS_NO_LIB") but, apparently, the DEPENDS in the above boost_test_run macro call does not cause boost_regex library to be built and loaded to create the iostreams regex_filter_test. Anyone have any suggestions about how to solve this? TIA. -regards, Larry [snip]
Larry Evans wrote:
So I looked at the iostreams test/Jamfile.v2 which showed regex_filter_test requiring boost_regex:
[ test-iostreams regex_filter_test.cpp /boost/regex//boost_regex ]
The corresponding line in iostreams test/CMakeLists.txt has:
boost_test_run(regex_filter_test DEPENDS boost_unit_test_framework boost_regex COMPILE_FLAGS "-DBOOST_IOSTREAMS_NO_LIB")
but, apparently, the DEPENDS in the above boost_test_run macro call does not cause boost_regex library to be built and loaded to create the iostreams regex_filter_test.
Anyone have any suggestions about how to solve this?
It's a known problem in boost-cmake. The way to fix it is to change how we handle BOOST_REGEX (library-selection option) and BOOST_STATIC (feature-selection option). It's probably not a huge change, but it has to be done in tools/build/CMake/BoostCore.cmake. The reason we haven't send out an announcement that the Boost-CMake system is ready for use is that, well, it isn't ready for prime-time yet. It handles the user-centric use cases well: building all of Boost, installing Boost, building binary packages, regression testing all of Boost. We haven't put much effort into more developer-centric uses, e.g., running tests for a single library. - Doug
On 08/17/2007 09:17 AM, Douglas Gregor wrote: [snip]
but, apparently, the DEPENDS in the above boost_test_run macro call does not cause boost_regex library to be built and loaded to create the iostreams regex_filter_test.
Anyone have any suggestions about how to solve this?
It's a known problem in boost-cmake. The way to fix it is to change how we handle BOOST_REGEX (library-selection option) and BOOST_STATIC (feature-selection option). It's probably not a huge change, but it has to be done in tools/build/CMake/BoostCore.cmake.
The reason we haven't send out an announcement that the Boost-CMake system is ready for use is that, well, it isn't ready for prime-time yet. It handles the user-centric use cases well: building all of Boost, installing Boost, building binary packages, regression testing all of Boost. We haven't put much effort into more developer-centric uses, e.g., running tests for a single library.
Yeah, that's understandable that user-centric comes first. I thought maybe that was the reason. Thanks again for the work so far :) -regards, Larry
On 08/14/2007 02:48 PM, Larry Evans wrote: [snip]
Now, on another problem. I tried cd to the build/libs/mpl and noticed a Makefile but no test subdirectory; so I tried invoking make, but nothing was compiled. I guess this directory has not yet been converted to use CMake. Is there one that has so I could test it out? Ignore the following line :( the src/libs/mpl/
OK, I guess I should have read: http://svn.boost.org/trac/boost/wiki/CMakeBuildConfiguration which contains: and you are presented with a list of editable build options something like this: BUILD_BOOST_DATE_TIME ON BUILD_BOOST_FILESYSTEM ON BUILD_BOOST_GRAPH ON BUILD_BOOST_IOSTREAMS ON so I guess this means if I want to just build graph, I turn all the other's off. Sorry for not reading far enough.
on Sun May 13 2007, "Dean Michael Berris" <dmberris-AT-friendster.com> wrote:
For whatever it's worth, I'd like to give my opinions about this issue.
I've personally handled some serious projects with serious build configurations which border from the trivial to the bizarre. I have had the experience of trying to build/port an application between Windows and Linux more than once while I also try to write libraries that will build on either platform. I've tried to do this before with "just auto-make and friends" and Boost.Build (v2 mostly) and I all I can say is that the first time I tried BBv2 it's simple enough to understand and use.
Now I haven't been using Boost (or developing for Boost (yet) for the matter) as long as others on the list have so I haven't experienced the pain of building BBv1 and then transitioning to BBv2. But I have been able to use BBv2 extensively in at least a couple of projects (two of which open source, and two of which not open source) and all I can say is that it's been a breeze to use.
What I particularly like about BBv2 is how easy it seems to make a Jamfile.v2 from scratch and modify it according to your later requirements without the pain you usually deal with in the Make family of tools. Although I understand the apprehension of maintaining the Jam sources (in C most of it) and even the Boost.Build .jam files, I for one have seen the benefits of such a system as being part of Boost.
I guess the thought of using something not-Boost maintained is brought about by the obvious hardships in maintaining .jam files in Boost.Build itself, and extending the tool chain as well as the mere maintenance of the code to fight fires and squash bugs that seem to be never ending.
Yup. Even with the new Getting Started Guide, just take a look at the number of complaints we've had on the user's list about being unable to build Boost 1.34. So far these are largely issues having to do with configuring the tools.
The apprehension I feel in adopting CMake is with the inertia and the investment a lot of people have put into (me included) understanding and using effectively not only the Boost library but the excellent build system that comes with it "for free". I think I won't be alone in saying that people who have been burnt by the sheer nightmare that is writing a Makefile and maintaining it (even with the autotools) welcome the breeze that is Boost.Build and Boost.Jam . I don't know if it might be the name "CMake" but anything (IMO) remotely related to Make just turns me and a lot of developers who've dealt with it before away.
:) I hear ya.
Now I guess it might be too much to ask, but what if we allow some CMake specific stuff into Boost -- I mean, just include the build files in there and not require the Boost library to restructure itself and/or the files if it would be possible -- and let the users choose whether to use Boost.Jam+Boost.Build or CMake when building Boost for their system, we might be doing everyone a service by providing viable alternatives.
Not everyone; it would just worsen the problem we're trying to solve. It would create confusion and demand for everyone to support both systems.
If someone wants to pick up the task of using CMake to build Boost and contribute that knowledge/effort into the library/project, then I don't see why we should abandon Boost.Build and Boost.Jam when people still seem to want to use it.
It might be a naive question, but why can't we let these build-system specific files reside in the distribution and let users pick which one works for them? I'm positive we can make the CMake and Boost.Build stuff reside in the same distribution and not have to abandon one in favor of another.
I for one wouldn't want to see Boost.Build or Boost.Jam deprecated because I've greatly benefited from these technologies greatly. I just wish I could help make them tools better, or at least help it be the tool that the community would like it to be.
The support we've seen for keeping Boost.Build alive is obviously significant and merits consideration. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On 5/16/07, David Abrahams <dave@boost-consulting.com> wrote:
on Sun May 13 2007, "Dean Michael Berris" <dmberris-AT-friendster.com> wrote:
I guess the thought of using something not-Boost maintained is brought about by the obvious hardships in maintaining .jam files in Boost.Build itself, and extending the tool chain as well as the mere maintenance of the code to fight fires and squash bugs that seem to be never ending.
Yup. Even with the new Getting Started Guide, just take a look at the number of complaints we've had on the user's list about being unable to build Boost 1.34. So far these are largely issues having to do with configuring the tools.
Someone (John Maddock I think) suggested we use something like a ./configure script which actually configured BBv2 for you -- i.e. edited your site-config.jam and/or user-config.jam file setting the correct/detected/configured toolkits. Might be worth looking at, and might even be interactive (Python anyone? ;) ). At any rate, I agree that there's a need to make the configuring Boost.Build easier -- and not require users to learn Jam before touching the configuration files.
Now I guess it might be too much to ask, but what if we allow some CMake specific stuff into Boost -- I mean, just include the build files in there and not require the Boost library to restructure itself and/or the files if it would be possible -- and let the users choose whether to use Boost.Jam+Boost.Build or CMake when building Boost for their system, we might be doing everyone a service by providing viable alternatives.
Not everyone; it would just worsen the problem we're trying to solve. It would create confusion and demand for everyone to support both systems.
I guess putting a disclaimer which says: "WARNING: using CMake is an option but is currently not *yet* the supported way of building Boost. If you encounter problems/issues with using CMake, please consider using Boost.Build to build Boost. If everything else fails, forward concerns to <insert users mailing list>." Might make sense, if the intention was to make CMake a viable option (and not replacement) for Boost.Build in the first few Boost releases. Much as some experienced developers in the field might disagree, "Users are not stupid." ;-)
I for one wouldn't want to see Boost.Build or Boost.Jam deprecated because I've greatly benefited from these technologies greatly. I just wish I could help make them tools better, or at least help it be the tool that the community would like it to be.
The support we've seen for keeping Boost.Build alive is obviously significant and merits consideration.
I guess now it's a matter of following up the support by converting "users" to "contributors". Lowering the barrier to entry might be a good first step, first by using more familiar (i.e. easier to use) tools for documentation, collaborative development (Trac+SVN of BBv2 anyone?), and a dedicated developer community (time based release system for BB?) working on Boost.Build alone might make more sense. That way, even if Boost does decide to use CMake, those still using Boost.Build in their organizations/projects will have a community to turn to when they need help. And people to throw their complaints / feature requests at. ;-) (Might be the wine+beer talking/typing... I'm not sure if I'll regret posting this "calling for arms to action" thing, but I do want to be part of this Boost.Build thing somehow. I'm particularly looking at building some support for a "Continuous Integration Environment" within Boost.Build which formatted outputs into nice HTML pages which might help in "remote building" and "regression testing") -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459
Hi all, and apologies for a technically uninteresting e-mail, I took the Mountain Express to get here, but their schedule would mean that I would have to miss the last session, which sounds pretty neat. Is anybody willing to give me a ride back to Denver on Friday afternoon? My flight is around midnight. I'd be willing to pay the $100 I'd otherwise be giving to CMEX. Thanks, Gordon
that's exactly my schedule. You are wellcome to join me, Gennadiy "Gordon Woodhull" <gordon@woodhull.com> wrote in message news:464B567D.3070707@woodhull.com...
Hi all, and apologies for a technically uninteresting e-mail,
I took the Mountain Express to get here, but their schedule would mean that I would have to miss the last session, which sounds pretty neat.
Is anybody willing to give me a ride back to Denver on Friday afternoon? My flight is around midnight. I'd be willing to pay the $100 I'd otherwise be giving to CMEX.
Thanks, Gordon _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Gordon - I'm going to do everything I can to make the last session on Fri (in particular the "Future of Boost" session). My flight from Denver is at 5:25 pm, though, so I'm not sure if that's going to work. It's likely I'm going to take the chance (there's later flights to Seattle I could take if I miss the 5:25 flight), but I will definitely leave right at 12:30 (or a little earlier), with everything packed in the rental car ready to go. In any case, you're welcome to join me - you will have quite a few hours to wait at the airport, of course. My tag says: Cliff Green Boeing I have a shaved bald head, so I'm pretty easy to find. This afternoon (Thu) I'll be in the concepts sessions. Good luck! Cliff On Wed, 16 May 2007 13:07:42 -0600 Gordon Woodhull <gordon@woodhull.com> wrote:
Hi all, and apologies for a technically uninteresting e-mail,
I took the Mountain Express to get here, but their schedule would mean that I would have to miss the last session, which sounds pretty neat.
Is anybody willing to give me a ride back to Denver on Friday afternoon? My flight is around midnight. I'd be willing to pay the $100 I'd otherwise be giving to CMEX.
Thanks, Gordon _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On May 16, 2007, at 12:46 PM, Dean Michael Berris wrote:
On 5/16/07, David Abrahams <dave@boost-consulting.com> wrote:
on Sun May 13 2007, "Dean Michael Berris" <dmberris-AT- friendster.com> wrote:
I guess the thought of using something not-Boost maintained is brought about by the obvious hardships in maintaining .jam files in Boost.Build itself, and extending the tool chain as well as the mere maintenance of the code to fight fires and squash bugs that seem to be never ending.
Yup. Even with the new Getting Started Guide, just take a look at the number of complaints we've had on the user's list about being unable to build Boost 1.34. So far these are largely issues having to do with configuring the tools.
Someone (John Maddock I think) suggested we use something like a ./configure script which actually configured BBv2 for you -- i.e. edited your site-config.jam and/or user-config.jam file setting the correct/detected/configured toolkits. Might be worth looking at, and might even be interactive (Python anyone? ;) ).
I wrote such a script, and it's there in $BOOST_ROOT. It only works on Unix-like systems, but it handles the simplest cases very well. - Doug
On 5/16/07, Douglas Gregor <doug.gregor@gmail.com> wrote:
On May 16, 2007, at 12:46 PM, Dean Michael Berris wrote:
Someone (John Maddock I think) suggested we use something like a ./configure script which actually configured BBv2 for you -- i.e. edited your site-config.jam and/or user-config.jam file setting the correct/detected/configured toolkits. Might be worth looking at, and might even be interactive (Python anyone? ;) ).
I wrote such a script, and it's there in $BOOST_ROOT. It only works on Unix-like systems, but it handles the simplest cases very well.
Cool! Thanks for the heads up Doug! Might be worth noting in the Getting Started document's section for Unix-like systems... Dave, what do you think? This begs the question though, how hard would it be to come up with something like this for other OSes (Windows, etc.) ? -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459
on Wed May 16 2007, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
On 5/16/07, Douglas Gregor <doug.gregor@gmail.com> wrote:
On May 16, 2007, at 12:46 PM, Dean Michael Berris wrote:
Someone (John Maddock I think) suggested we use something like a ./configure script which actually configured BBv2 for you -- i.e. edited your site-config.jam and/or user-config.jam file setting the correct/detected/configured toolkits. Might be worth looking at, and might even be interactive (Python anyone? ;) ).
I wrote such a script, and it's there in $BOOST_ROOT. It only works on Unix-like systems, but it handles the simplest cases very well.
Cool! Thanks for the heads up Doug!
Might be worth noting in the Getting Started document's section for Unix-like systems... Dave, what do you think?
Umm... have you read that document? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On 5/16/07, David Abrahams <dave@boost-consulting.com> wrote:
on Wed May 16 2007, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
Might be worth noting in the Getting Started document's section for Unix-like systems... Dave, what do you think?
Umm... have you read that document?
What I read was the one you posted about a while back... It's obviously different than the one in http://boost.org/more/getting_started/unix-variants.html now. ./configure is being described to be used along with make. I was under the impression that it could be used with Boost.Jam, and so I was looking for a combo which did the following: $ ./configure --your-options $ bjam stage Instead of the seemingly (and actually) more complicated: $ bjam --build-dir=/tmp/build-boost --toolset=gcc stage Or am I understanding it wrong? -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459
on Thu May 17 2007, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
On 5/16/07, David Abrahams <dave@boost-consulting.com> wrote:
on Wed May 16 2007, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
Might be worth noting in the Getting Started document's section for Unix-like systems... Dave, what do you think?
Umm... have you read that document?
What I read was the one you posted about a while back... It's obviously different than the one in http://boost.org/more/getting_started/unix-variants.html now.
./configure is being described to be used along with make. I was under the impression that it could be used with Boost.Jam, and so I was looking for a combo which did the following:
Well it probably can, but make is just going to (if necessary, build and) invoke bjam anyway.
$ ./configure --your-options $ bjam stage
Instead of the seemingly (and actually) more complicated:
$ bjam --build-dir=/tmp/build-boost --toolset=gcc stage
Or am I understanding it wrong?
I guess you're understanding it wrong. "./configure && make install" is much much simpler than anything that requires the user to acquire a bjam binary. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
on Wed May 16 2007, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
This begs the question though, how hard would it be to come up with something like this for other OSes (Windows, etc.) ?
That's exactly what CMake does (among other things). -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On 5/16/07, David Abrahams <dave@boost-consulting.com> wrote:
on Wed May 16 2007, "Dean Michael Berris" <mikhailberis-AT-gmail.com> wrote:
This begs the question though, how hard would it be to come up with something like this for other OSes (Windows, etc.) ?
That's exactly what CMake does (among other things).
Okay, but that doesn't answer the question of "how hard would it be to come up with something like this [a configure script] for other OSes" in the spirit of continuing to use BBv2 -- not only for Boost but for other projects that use BBv2 as well. Obviously the above remark indicates that there's no interest (at least from Dave) in exploring that route at least from the Boost C++ Library building perspective. Anybody else has any idea about it [writing a Windows native configure script]? -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459
Douglas Gregor wrote:
Someone (John Maddock I think) suggested we use something like a ./configure script which actually configured BBv2 for you -- i.e. edited your site-config.jam and/or user-config.jam file setting the correct/detected/configured toolkits. Might be worth looking at, and might even be interactive (Python anyone? ;) ).
I wrote such a script, and it's there in $BOOST_ROOT. It only works on Unix-like systems, but it handles the simplest cases very well.
Exactly, the idea was to enhance the script to handle CXX/CXXFLAGS/LDFLAGS etc, so users could build with compilers not necessarily supported by Boost.Build yet. John.
on Thu May 17 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
Douglas Gregor wrote:
Someone (John Maddock I think) suggested we use something like a ./configure script which actually configured BBv2 for you -- i.e. edited your site-config.jam and/or user-config.jam file setting the correct/detected/configured toolkits. Might be worth looking at, and might even be interactive (Python anyone? ;) ).
I wrote such a script, and it's there in $BOOST_ROOT. It only works on Unix-like systems, but it handles the simplest cases very well.
Exactly, the idea was to enhance the script to handle CXX/CXXFLAGS/LDFLAGS etc, so users could build with compilers not necessarily supported by Boost.Build yet.
There's no chance of that. BB is not prepared to run arbitrary compilers, and make just invokes bjam. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
David Abrahams wrote:
Exactly, the idea was to enhance the script to handle CXX/CXXFLAGS/LDFLAGS etc, so users could build with compilers not necessarily supported by Boost.Build yet.
There's no chance of that. BB is not prepared to run arbitrary compilers, and make just invokes bjam.
Sure, but with a "generic" toolset that used CXX/CXXFLAGS etc to run an arbitrary compiler, we surely could support that? John.
I've been quietly watching this discussion with some interest since I have invested time of my own in the past few years building portable build systems. I currently use a gmake-based build system - with careful crafting this can support "plug-in" compiler environments as well as support for "trivial" makefiles. Gmake is widely available on multiple platforms as well as being an off-the-shelf solution. Maybe I'm missing something but I'm curious as to why no-one has suggested this as an option Andrew -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Friday, May 18, 2007 4:59 AM To: boost@lists.boost.org Subject: Re: [boost] Boost building with CMake David Abrahams wrote:
Exactly, the idea was to enhance the script to handle CXX/CXXFLAGS/LDFLAGS etc, so users could build with compilers not necessarily supported by Boost.Build yet.
There's no chance of that. BB is not prepared to run arbitrary compilers, and make just invokes bjam.
Sure, but with a "generic" toolset that used CXX/CXXFLAGS etc to run an arbitrary compiler, we surely could support that? John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Earnes, On 5/18/07, Eames, Andrew <andrew@cognex.com> wrote:
I've been quietly watching this discussion with some interest since I have invested time of my own in the past few years building portable build systems. I currently use a gmake-based build system - with careful crafting this can support "plug-in" compiler environments as well as support for "trivial" makefiles. Gmake is widely available on multiple platforms as well as being an off-the-shelf solution. Maybe I'm missing something but I'm curious as to why no-one has suggested this as an option
Gmake is the same sa GNU Make right? Not to throw dirt at GNU Make, but it's just too hard and too painful to maintain complex project builds with it. Whether by hand or with auto-tools. Compare that to the trivial Jamfiles that are smart enough to figure out what to do when you say: exe main : main.cpp ; And be cross-platform right off the bat. Hope this makes sense. -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459
Dean Michael Berris wrote:
Not to throw dirt at GNU Make, but it's just too hard and too painful to maintain complex project builds with it. Whether by hand or with auto-tools.
Compare that to the trivial Jamfiles that are smart enough to figure out what to do when you say:
exe main : main.cpp ;
And be cross-platform right off the bat.
I don't think it's fair to compare (GNU) make with boost.build, as 'make' itself operates more on the level of bjam. I'm fairly positive that something akin to boost.build could be written on top of 'make', too, i.e. a set of makefiles, together with conventions how to use them. In fact, as much problems as there exist with (GNU) make, the single most important advantage it has is that there are more people knowing it (its syntax, semantics, flaws, and ways to work with and around them). Throwing that advantage away shouldn't be taken lightly. (And, as it happens, the single most important disadvantage I see with bjam is exactly the same: new syntax, new (and grossly underdocumented) semantics, and very few people who really understand all that.) FWIW, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Hi Stefan, On 5/18/07, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Dean Michael Berris wrote:
Not to throw dirt at GNU Make, but it's just too hard and too painful to maintain complex project builds with it. Whether by hand or with auto-tools.
Compare that to the trivial Jamfiles that are smart enough to figure out what to do when you say:
exe main : main.cpp ;
And be cross-platform right off the bat.
I don't think it's fair to compare (GNU) make with boost.build, as 'make' itself operates more on the level of bjam. I'm fairly positive that something akin to boost.build could be written on top of 'make', too, i.e. a set of makefiles, together with conventions how to use them.
I think this was the idea in CMake, which made makefiles (among other things) for you. I don't think Boost.Build does what CMake does, in the sense that the Boost.Build system itself does the building while CMake will rely on an external/different build system to actually do a build. Please correct me if this assessment is wrong. Now comparing 'bjam' and 'make' would be moot because they're apples and oranges: two completely different things which did things differently. However, since they both do the actual build by invoking compilers, linkers, archivers, code generators, etc. then let's say we should be able to compare the way you configure them to run: Makefiles and Jamfiles. If there was ever a direct comparison between a Makefile and a Jamfile, then I'd like to see a link. If there isn't one yet, please let me try to give one trivial comparison between the Makefile and Jamfile -- one Makefile generated by hand, and another Jamfile generated by hand. Makefile: CC=g++ CFLAGS=-Wall %.o: %.cpp $(CC) $(CFLAGS) -c $^ main: main.o some_other_file.o $(CC) $(CFLAGS) -o $< $^ Jamfile: exe main : main.cpp some_other_file.cpp ; Like I said, apples and oranges. ;-)
In fact, as much problems as there exist with (GNU) make, the single most important advantage it has is that there are more people knowing it (its syntax, semantics, flaws, and ways to work with and around them).
Throwing that advantage away shouldn't be taken lightly.
I don't mean to turn this into a philosophical debate, but just because people know how to do mental math doesn't mean they wouldn't benefit from knowing how to use a calculator. We're not throwing away the advantage of people knowing how to do mental math, but we're not also saying that everyone should use a calculator. So the reason Boost.Build+Boost.Jam are the way they are is most likely because it was meant to be different from Make and attempts to do a better job than Make. It is direct competition but it was never meant to be built to take over the world of build systems -- at least as how I see it, it's an alternative which actually works and in some cases (nay, most I would say) does better than Make.
(And, as it happens, the single most important disadvantage I see with bjam is exactly the same: new syntax, new (and grossly underdocumented) semantics, and very few people who really understand all that.)
How would a different syntax be a disadvantage? I'm sorry, it's like saying since Python has a different syntax from C++ is that the syntax is a disadvantage. The undocumented semantics can be addressed and people are actually starting to do something about it. Please see the Boost.Build mailing list(s) if you want to be part of that discussion. If it's not obvious yet, *I don't like Make because I've been burn too many times with it*. Even though Boost.Jam and Boost.Build use a different syntax, that didn't stop me (and others) from using it. And I actually welcome the change from syntax, much like how C++'s syntax is a welcome change from Pascal. Again, I think it boils down to recognizing what you need and expressing what needs to be done with a tool you're familiar with. I guess it's "to each his own". :-) FWIW. -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459
On 05/18/2007 11:09 AM, Dean Michael Berris wrote:
Hi Stefan,
On 5/18/07, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Dean Michael Berris wrote:
Not to throw dirt at GNU Make, but it's just too hard and too painful to maintain complex project builds with it. Whether by hand or with auto-tools.
Compare that to the trivial Jamfiles that are smart enough to figure out what to do when you say:
exe main : main.cpp ;
And be cross-platform right off the bat. I don't think it's fair to compare (GNU) make with boost.build, as 'make' itself operates more on the level of bjam. I'm fairly positive that something akin to boost.build could be written on top of 'make', too, i.e. a set of makefiles, together with conventions how to use them.
I think this was the idea in CMake, which made makefiles (among other things) for you. I don't think Boost.Build does what CMake does, in the sense that the Boost.Build system itself does the building while CMake will rely on an external/different build system to actually do a build. Please correct me if this assessment is wrong.
Now comparing 'bjam' and 'make' would be moot because they're apples and oranges: two completely different things which did things differently. However, since they both do the actual build by invoking compilers, linkers, archivers, code generators, etc. then let's say we should be able to compare the way you configure them to run: Makefiles and Jamfiles.
If there was ever a direct comparison between a Makefile and a Jamfile, then I'd like to see a link. If there isn't one yet, please let me try to give one trivial comparison between the Makefile and Jamfile -- one Makefile generated by hand, and another Jamfile generated by hand.
Makefile:
CC=g++ CFLAGS=-Wall
%.o: %.cpp $(CC) $(CFLAGS) -c $^
main: main.o some_other_file.o $(CC) $(CFLAGS) -o $< $^
Jamfile:
exe main : main.cpp some_other_file.cpp ;
Like I said, apples and oranges. ;-)
I don't see much difference unless you're just referring to the amount of typing. However, in that case, you could just use gmake's include to "import" a library of macros, somewhat like bjam's import. Now as for as selecting different compilers and putting the resuling .o and .a and .exe files in different directories, this could also be done with gmake. For example: MAIN ?= main BUILD.dir ?= $(PROJECT.dir)/build RELEASE.dir ?= $(PROJECT.dir)/release ################### HOW=gcc #HOW=gccv #HOW=icc #HOW=como BUILD_HOW.dir:=$(BUILD.dir)/$(HOW) VARIADIC.dir=/home/evansl/download/gcc/variadic-templates VARISNAP.dir=$(VARIADIC.dir)/gcc-4.3-20070323 COMPILER.gcc=/usr/bin/g++-4.1 COMPILER.gccv=$(VARISNAP.dir)/install/bin/g++ COMPILER.src.gccv=$(VARIADIC.dir)/gcc-4.1.1 COMPILER.src.gcc=$(VARIADIC.dir)gcc-4.1.1-download/gcc-4.1.1-non-var/gcc-4.1.1 COMPILER.src.file=gcc/cp/pt.c COMPILER.icc=/home/evansl/intel/cc/9.1.043/bin/icc COMPILER.como=como Of course you might be saying, "but that's so much typing", and the natural response is, agin, gmake include. With the help of some perl or python utilities, you could so somthing like the way bjam searches for the boost root: DIR.root := $(shell dirup_dir_file.pl $(PWD) root.imk) When put inside a gmake file, this searches up in the paraent directories until it finds root.imk (corresponding to boost-root.jam, I guess). Again, I know it seems a lot of behind the scenes work, but no more so (really a lot less) than what bjam does. The problem I had with this gmake include approach was that I couldn't figure a way to emulate bjam's projects. IOW, bjam projects and the method for invoking them overcomes , I guess, the problems with recursive Makes. I've heard recursive makes are a problem, but I don't really understand all the details, but I can see one problem is the namespace conflict. IOW, all the macros in different recursions of make would or might interfere. Again I'm guessing. In summmary, your example, at least to me, doesn't illustrate a real advantage of bjam vs gmake. -best regards, Larry
Larry Evans wrote:
MAIN ?= main BUILD.dir ?= $(PROJECT.dir)/build RELEASE.dir ?= $(PROJECT.dir)/release ################### HOW=gcc #HOW=gccv #HOW=icc #HOW=como BUILD_HOW.dir:=$(BUILD.dir)/$(HOW) VARIADIC.dir=/home/evansl/download/gcc/variadic-templates VARISNAP.dir=$(VARIADIC.dir)/gcc-4.3-20070323 COMPILER.gcc=/usr/bin/g++-4.1 COMPILER.gccv=$(VARISNAP.dir)/install/bin/g++ COMPILER.src.gccv=$(VARIADIC.dir)/gcc-4.1.1 COMPILER.src.gcc=$(VARIADIC.dir)gcc-4.1.1-download/gcc-4.1.1-non-var/gcc-4.1.1 COMPILER.src.file=gcc/cp/pt.c COMPILER.icc=/home/evansl/intel/cc/9.1.043/bin/icc COMPILER.como=como
This style reminded me of pkgsrc - my favorite system to build software from sources. I run it successfully on FreeBSD, Linux and OpenBSD. Worth looking at how far it can go, it is able to build a world! http://www.netbsd.org/Documentation/pkgsrc/ Or you can jump straight to Makefiles: http://cvsweb.netbsd.se/cgi-bin/bsdweb.cgi/pkgsrc/meta-pkgs/boost/ -- Alexander Nasonov http://nasonov.blogspot.com Every government is a scoundrel. -- Henry Mencken -- This quote is generated by: /usr/pkg/bin/curl -L http://tinyurl.com/veusy \ | sed -e 's/^document\.write(.//' -e 's/.);$/ --/' \ -e 's/<[^>]*>//g' -e 's/^More quotes from //' \ | fmt | tee ~/.signature-quote
"Dean Michael Berris" <dmberris@friendster.com> writes:
If there was ever a direct comparison between a Makefile and a Jamfile, then I'd like to see a link. If there isn't one yet, please let me try to give one trivial comparison between the Makefile and Jamfile -- one Makefile generated by hand, and another Jamfile generated by hand.
Makefile:
CC=g++ CFLAGS=-Wall
%.o: %.cpp $(CC) $(CFLAGS) -c $^
main: main.o some_other_file.o $(CC) $(CFLAGS) -o $< $^
That's overly verbose: most of these rules are built in to make. My simple makefile says: main: main.cpp some_other_file.cpp
Jamfile:
exe main : main.cpp some_other_file.cpp ;
Like I said, apples and oranges. ;-)
;-) Simple projects are easy with make, and easy with Boost Build. From what I've seen, complex projects are complex with both, too. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Anthony Williams wrote:
Simple projects are easy with make, and easy with Boost Build. From what I've seen, complex projects are complex with both, too.
I don't agree. Creating a makefile that works with one type of compiler is not too hard if you only want to work on one platform. However, I would like to see the "easy makefile" that builds shared libraries on OSX, windows, linux, hp, sun, IRIX, and QNX, and supports multiple compilers on each of those platforms. Both CMake and bjam can create a shared library like that with a very simple input file. In CMake, it is add_library(foo SHARED foo.cxx) CMake also provides a mechanism for system introspection, so you can program to the canonical machine, and have ifdefs in your code based on features and not systems. make by itself can not do any of that. -Bill
On 5/18/07, Anthony Williams <anthony_w.geo@yahoo.com> wrote:
"Dean Michael Berris" <dmberris@friendster.com> writes:
[snipped my biased example]
That's overly verbose: most of these rules are built in to make.
My simple makefile says:
main: main.cpp some_other_file.cpp
Okay... I might be rusty with Make, but shouldn't that be: main: main.o some_other_file.o ? Nonetheless...
Jamfile:
exe main : main.cpp some_other_file.cpp ;
Like I said, apples and oranges. ;-)
;-)
Simple projects are easy with make, and easy with Boost Build. From what I've seen, complex projects are complex with both, too.
After all that's said and done, I would tend to agree with this statement. :-D I guess it just depends on your level of expertise and chosen approach to accomplishing a task with a given tool you're familiar with. Of course, people familiar with Make and adept at it will prefer that over a "wannabe replacement" like Boost.Build + Boost.Jam where they'd have to learn a new syntax. Or maybe not, depends on how they approach the problem and how they see Boost.Build + Boost.Jam. :-) Some people like inline skates, others like old-skool skates. Apples and Oranges -- both fruit, but different flavors. ;-) -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459
"Dean Michael Berris" <dmberris@friendster.com> writes:
On 5/18/07, Anthony Williams <anthony_w.geo@yahoo.com> wrote:
"Dean Michael Berris" <dmberris@friendster.com> writes:
[snipped my biased example]
That's overly verbose: most of these rules are built in to make.
My simple makefile says:
main: main.cpp some_other_file.cpp
Okay... I might be rusty with Make, but shouldn't that be:
main: main.o some_other_file.o
No, specifying source files works just fine. On my system it produces one command: g++ -o main main.cpp some_other_file.cpp Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Dean Michael Berris wrote:
Makefile:
CC=g++ CFLAGS=-Wall
%.o: %.cpp $(CC) $(CFLAGS) -c $^
main: main.o some_other_file.o $(CC) $(CFLAGS) -o $< $^
Jamfile:
exe main : main.cpp some_other_file.cpp ;
I may be misunderstanding how bjam works, but I don't think it knows by itself what to do with that line. It may, at most, include default commands (similarly to what GNU make provides) to make this work. So, I doubt this is a meaningful comparison. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 5/18/07, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Dean Michael Berris wrote:
Jamfile:
exe main : main.cpp some_other_file.cpp ;
I may be misunderstanding how bjam works, but I don't think it knows by itself what to do with that line. It may, at most, include default commands (similarly to what GNU make provides) to make this work.
You're actually right, I mixed up Boost.Build and Boost.Jam in this case... My bad.
So, I doubt this is a meaningful comparison.
True. Sorry for the noise. :-) -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459
I've been quietly watching this discussion with some interest since I have invested time of my own in the past few years building portable build systems. I currently use a gmake-based build system - with careful crafting
Nope - it doesn't make sense at all. I have an existing cross platform build system based on gmake An example of one of my makefiles to build 3 files into a library looks like this ---------------------------------- SOURCES = foo.cpp bar.cpp baz.cpp LIBRARY = libWombat Include <master makefile> ---------------------------------- This is trivial to edit by our developers, trivial to add new platform support and uses a standard toolset Andrew -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Dean Michael Berris Sent: Friday, May 18, 2007 10:56 AM To: boost@lists.boost.org Subject: Re: [boost] Boost building with CMake Hi Earnes, On 5/18/07, Eames, Andrew <andrew@cognex.com> wrote: this
can support "plug-in" compiler environments as well as support for "trivial" makefiles. Gmake is widely available on multiple platforms as well as being an off-the-shelf solution. Maybe I'm missing something but I'm curious as to why no-one has suggested this as an option
Gmake is the same sa GNU Make right? Not to throw dirt at GNU Make, but it's just too hard and too painful to maintain complex project builds with it. Whether by hand or with auto-tools. Compare that to the trivial Jamfiles that are smart enough to figure out what to do when you say: exe main : main.cpp ; And be cross-platform right off the bat. Hope this makes sense. -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible. Teach CanIt if this mail (ID 8396993) is spam: Spam: http://mail-gw.cognex.com/canit/b.php?c=s&i=8396993&m=2b0f74add96e Not spam: http://mail-gw.cognex.com/canit/b.php?c=n&i=8396993&m=2b0f74add96e Forget vote: http://mail-gw.cognex.com/canit/b.php?c=f&i=8396993&m=2b0f74add96e ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS
Dean Michael Berris wrote:
Not to throw dirt at GNU Make, but it's just too hard and too painful to maintain complex project builds with it. Whether by hand or with auto-tools.
Compare that to the trivial Jamfiles that are smart enough to figure out what to do when you say:
exe main : main.cpp ;
FWIW, that can be done with gmake, too. E.g. I do things like this in my projects: foo_sources = foo.cpp bar.cpp baz.idl apps = foo include make.common and get some level (*) of cross-platformness, too. You can't say cross-platform builds like that aren't possible with gmake. It takes time to develop the harness, but that's true with any build system. Note, I'm not suggesting a switch to make-based systems here. Boost.Build seems to be pretty well developed and a switch back to square one of a different basic build system would not earn us anything. Regards, m *) "some level" because I have a set of platforms to support that is significantly smaller than Boost.Build's range of platforms. However, I think anything that can be done with bjam could be done with gmake, too.
Hi Martin! On 5/18/07, Martin Wille <mw8329@yahoo.com.au> wrote:
Dean Michael Berris wrote:
[snpped my biased argument]
You can't say cross-platform builds like that aren't possible with gmake. It takes time to develop the harness, but that's true with any build system.
I wasn't implying that gmake builds are impossible. I was saying more to the effect that it's too hard to do that, especially if your platform is Windows -- because even gmake's "native" Windows port isn't the best, and sometimes cygwin and mingw aren't viable alternatives. That's why Boost.Build is very attractive for people like me, who just want to maintain one Jamfile which pretty much produces the desired output as much as possible in as much platforms as possible. Library writers love this because Boost.Build does it for the library writers "for free" without the required additional mental cartwheels that gmake requires developers to perform (like you've said, the harness takes time to develop -- time which is something no self respecting developer ever has ;) ). Though we'd like to take advantage of Boost.Build more, the problem like it's always been brought out and widely accepted is the documentation. Then there's also the issue of easy compartmentalization of the build instructions for your project. Something very hard to achieve with Make.
Note, I'm not suggesting a switch to make-based systems here. Boost.Build seems to be pretty well developed and a switch back to square one of a different basic build system would not earn us anything.
I guess the whole discussion with CMake has to do with the prospect of "not having to worry about writing Makefiles, VCS IDE project files, XCode project files, and <insert other build systems supported by CMake here>. So as far as CMake is concerned, I believe the argument is that it should be able to configure the build process for your build system of choice -- as long as CMake supports it. I for one do accept that this prospect is attractive, but assert that people like me still want to use Boost.Build, and would accept CMake if it really fits the bill for Boost but still aim to make Boost.Build the build system I would still want to use for my projects. FWIW. :-)
However, I think anything that can be done with bjam could be done with gmake, too.
I don't know about anything... Reading Jamfiles would be something gmake might not like to do. ;-) -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459
I have had some difficulty using the current version of the reverse_graph adapter on the Boost Graph Library. It seems to require the class being reversed to have types that a user class that has been adapted using graph_traits et al may not have. I have attached an example that shows the problem which includes comments to describe what I think the problem is. I have also attached a modified version of reverse_graph.hpp that works with this example. I would appreciate any help. Thanks, -Tony Attached files: bug_report_example_skeleton.hpp An include file the contains a minimal user defined graph MyGraph together with the required interfaces to adapt it to be a Boost Graph. bug_report_example_reverse_graph.cpp An example showing the problems encountered with the current reverse_graph.hpp reverse_graph.hpp An altered version of reverse_graph.hpp that works with the example.
on Fri May 18 2007, "Tye, Tony" <Tony.Tye-AT-amd.com> wrote:
I have had some difficulty using the current version of the reverse_graph adapter on the Boost Graph Library.
http://boost.org/more/discussion_policy.htm#effective -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
on Fri May 18 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
David Abrahams wrote:
Exactly, the idea was to enhance the script to handle CXX/CXXFLAGS/LDFLAGS etc, so users could build with compilers not necessarily supported by Boost.Build yet.
There's no chance of that. BB is not prepared to run arbitrary compilers, and make just invokes bjam.
Sure, but with a "generic" toolset that used CXX/CXXFLAGS etc to run an arbitrary compiler, we surely could support that?
What are you proposing gets done with platform/compiler-independent build properties that are in existing Jamfiles? Do they just disappear, or do they get translated into one person's idea of a standard compiler flag? What does "support" mean in either case? What do we tell people when their builds don't work? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Sure, but with a "generic" toolset that used CXX/CXXFLAGS etc to run an arbitrary compiler, we surely could support that?
What are you proposing gets done with platform/compiler-independent build properties that are in existing Jamfiles? Do they just disappear, or do they get translated into one person's idea of a standard compiler flag? What does "support" mean in either case? What do we tell people when their builds don't work?
Dave, at present if the compiler is unsupported the user gets no help from us at all, the same issue exists with CMake and/or autotools - but at least those two give the users a sporting chance of compiling with their "unknown" compiler if they can figure out what CXXFLAGS to use. I'm suggesting we do the same thing. Existing supported toolsets remain unchanged. The 99% case where the user is using a version of gcc but with custom invoke/compiler options could be detected (autoconf does this already) and forwarded to our gcc toolset presumably. I had meant to test this out by now, but you know time etc... John.
on Tue May 22 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
David Abrahams wrote:
Sure, but with a "generic" toolset that used CXX/CXXFLAGS etc to run an arbitrary compiler, we surely could support that?
What are you proposing gets done with platform/compiler-independent build properties that are in existing Jamfiles? Do they just disappear, or do they get translated into one person's idea of a standard compiler flag? What does "support" mean in either case? What do we tell people when their builds don't work?
Dave, at present if the compiler is unsupported the user gets no help from us at all, the same issue exists with CMake and/or autotools - but at least those two give the users a sporting chance of compiling with their "unknown" compiler if they can figure out what CXXFLAGS to use.
I understand that.
I'm suggesting we do the same thing.
We have different constraints. We don't have low-level build descriptions as in Makefiles.
Existing supported toolsets remain unchanged. The 99% case where the user is using a version of gcc but with custom invoke/compiler options could be detected (autoconf does this already) and forwarded to our gcc toolset presumably.
I had meant to test this out by now, but you know time etc...
You're not answering my questions. What about the platform/compiler-independent build properties when they appear in Jamfiles? Are they ignored, or do they get translated somehow, or what? FWIW, it was a design goal of Boost.Build v2 to get away from builds that depend on environment variables. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On May 22, 2007, at 10:53 AM, David Abrahams wrote:
FWIW, it was a design goal of Boost.Build v2 to get away from builds that depend on environment variables.
We combined configuration and build steps into one pass, somewhat confusing the issue. When there are separate "configure" and "build" steps, it makes sense for the "configure" step to obey environment variables whereas the "build" step would not. - Doug
Doug Gregor wrote:
On May 22, 2007, at 10:53 AM, David Abrahams wrote:
FWIW, it was a design goal of Boost.Build v2 to get away from builds that depend on environment variables.
We combined configuration and build steps into one pass, somewhat confusing the issue. When there are separate "configure" and "build" steps, it makes sense for the "configure" step to obey environment variables whereas the "build" step would not.
It seems perfectly reasonable to create such a generic toolset, whether it uses env vars or not. Doing this was on my todo list once upon a time. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
David Abrahams wrote:
on Tue May 22 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
David Abrahams wrote:
Sure, but with a "generic" toolset that used CXX/CXXFLAGS etc to run an arbitrary compiler, we surely could support that?
Yes, we could.
I'm suggesting we do the same thing.
We have different constraints. We don't have low-level build descriptions as in Makefiles.
Sure, but having such a toolset would give others a place to start in developing their own toolset.
Existing supported toolsets remain unchanged. The 99% case where the user is using a version of gcc but with custom invoke/compiler options could be detected (autoconf does this already) and forwarded to our gcc toolset presumably.
I had meant to test this out by now, but you know time etc...
You're not answering my questions. What about the platform/compiler-independent build properties when they appear in Jamfiles? Are they ignored, or do they get translated somehow, or what?
That lost me... Could you give an example? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
on Tue May 22 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
You're not answering my questions. What about the platform/compiler-independent build properties when they appear in Jamfiles? Are they ignored, or do they get translated somehow, or what?
That lost me... Could you give an example?
Suppose a target has <threading>multi in its requirements? What happens to that information? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Tue May 22 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
Existing supported toolsets remain unchanged. The 99% case where the user is using a version of gcc but with custom invoke/compiler options could be detected (autoconf does this already) and forwarded to our gcc toolset presumably.
I had meant to test this out by now, but you know time etc...
You're not answering my questions. What about the platform/compiler-independent build properties when they appear in Jamfiles? Are they ignored, or do they get translated somehow, or what?
Yes, they would be ignored, what else can you do if you don't recognise the compiler? The thing is true whatever the build system.
FWIW, it was a design goal of Boost.Build v2 to get away from builds that depend on environment variables.
Absolutely, but the suggestion is meant to help folks that are doing unusual things with unusual compilers, not for folks with known toolsets. Likewise to make the configure script behave as most folks expect them to. John.
on Wed May 16 2007, "Dean Michael Berris" <dmberris-AT-friendster.com> wrote:
Might make sense, if the intention was to make CMake a viable option (and not replacement) for Boost.Build in the first few Boost releases.
The intention is to make it a replacement, or there's little point. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
On 5/16/07, David Abrahams <dave@boost-consulting.com> wrote:
on Wed May 16 2007, "Dean Michael Berris" <dmberris-AT-friendster.com> wrote:
Might make sense, if the intention was to make CMake a viable option (and not replacement) for Boost.Build in the first few Boost releases.
The intention is to make it a replacement, or there's little point.
Now the question is when CMake is used as a replacement, do we want that immediately in the next release? Or would it be something that could wait over a couple of releases gradually phasing out BBv2? -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459
participants (47)
-
Alexander Nasonov -
Ames, Andreas (Andreas) -
Anthony Williams -
Bill Hoffman -
Boris Gubenko -
Brad King -
Braddock Gaskill -
Brook Milligan -
Cliff Green -
Darren Garvey -
David Abrahams -
Dean Michael Berris -
Dean Michael Berris -
Deane Yang -
Doug Gregor -
Douglas Gregor
-
Douglas Gregor -
Douglas Gregor -
Eames, Andrew -
Eric Niebler -
Felipe Magno de Almeida -
Gennadiy Rozental -
Glenn Schrader -
Gordon Woodhull -
Jeff Garland -
Jody Hagins -
Johan Nilsson -
John Biddiscombe -
John Maddock -
K. Noel Belcourt -
Kevin Wheatley -
Larry Evans -
Maik Beckmann -
Manfred Doudar -
Martin Wille -
Matthias Schabel -
Matthias Troyer -
Michael Caisse -
Michael Marcin -
Michael Marcin -
Rene Rivera -
Sohail Somani -
Stefan Seefeld -
Thomas Witt -
Toon Knapen -
Tye, Tony -
Vladimir Prus