Summer of Code 2006
Hello, Google has just announced that there will be a Summer of Code program this year. More information can be found here: http://code.google.com/soc/ I'm posting this message in the hope that Boost joins as a mentoring organization. I think this was discussed the last year, but it was not on the final organizations list. The goal could be to develop one of the "missing" libraries (those described in the Wiki, for example) following the advice of people from this list. And possibly get a library that is ready for review and inclusion into Boost. I know it's a difficult process, but there are three full months to spend on the task. If this happens, I'll certainly apply to work on the Boost.Process library. Cheers, -- Julio M. Merino Vidal <jmmv84@gmail.com> The Julipedia - http://julipedia.blogspot.com/
On Fri, 14 Apr 2006 23:22:51 +0200, Julio M. Merino Vidal wrote
Hello,
Google has just announced that there will be a Summer of Code program this year. More information can be found here:
I'm posting this message in the hope that Boost joins as a mentoring organization. I think this was discussed the last year, but it was not on the final organizations list.
I think we were a little late getting orginzied on this -- we found out about it after the list of mentoring organizations were already closed. Anyway, at least one of the mail threads started here: http://lists.boost.org/Archives/boost/2005/05/87606.php
The goal could be to develop one of the "missing" libraries (those described in the Wiki,
Perhaps the unicode char/string support would be something that is doable if mentored appropriately.
for example) following the advice of people from this list.
I don't think the mentoring can be as general as 'people from the list'. We need to have specific people/organizations identified. We'll need to submit a request and such: http://code.google.com/soc/mentorfaq.html
And possibly get a library that is ready for review and inclusion into Boost. I know it's a difficult process, but there are three full months to spend on the task.
If this happens, I'll certainly apply to work on the Boost.Process library.
Sounds like good one to me :-) Jeff
On 4/15/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
On Fri, 14 Apr 2006 23:22:51 +0200, Julio M. Merino Vidal wrote
Hello,
Google has just announced that there will be a Summer of Code program this year. More information can be found here:
I'm posting this message in the hope that Boost joins as a mentoring organization. I think this was discussed the last year, but it was not on the final organizations list.
I think we were a little late getting orginzied on this -- we found out about it after the list of mentoring organizations were already closed.
There is still some time left this year ;-)
for example) following the advice of people from this list.
I don't think the mentoring can be as general as 'people from the list'. We need to have specific people/organizations identified.
Sure not. Some specific mentors (one, two) would need to be specified for each project. But they could ask the students to post their questions in the open (that is, in this list) for wider discussion. That's why I said "people from this list".
We'll need to submit a request and such:
So... I'm curious. Are you going to do it? :-) Kind regards, -- Julio M. Merino Vidal <jmmv84@gmail.com> The Julipedia - http://julipedia.blogspot.com/
On Sun, 16 Apr 2006 11:40:07 +0200, Julio M. Merino Vidal wrote
On 4/15/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
for example) following the advice of people from this list.
I don't think the mentoring can be as general as 'people from the list'. We need to have specific people/organizations identified.
Sure not. Some specific mentors (one, two) would need to be specified for each project. But they could ask the students to post their questions in the open (that is, in this list) for wider discussion. That's why I said "people from this list".
Ok, but I don't think that works in general. Having been a student mentor a couple times in other contexts, it requires a certain amount of adminstrative and other guidance that I don't think can rightly come from the Boost list. For review of technical approaches and other questions the list would be fine.
We'll need to submit a request and such:
So... I'm curious. Are you going to do it? :-)
Personally I'm thinking I would be smart not to take on another project. I have a cronic habit of getting over-booked (is there a 12 step program for this problem ;-) -- anyway, I'm hoping we will be able to support a number of projects. Actually, I'm a little suprised there hasn't been more response to your post. I'm starting a discussion amoungst the moderators about how we want to organize to take this on. Jeff
Jeff Garland wrote:
On Sun, 16 Apr 2006 11:40:07 +0200, Julio M. Merino Vidal wrote
On 4/15/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
We'll need to submit a request and such:
http://code.google.com/soc/mentorfaq.html So... I'm curious. Are you going to do it? :-)
Personally I'm thinking I would be smart not to take on another project. I have a cronic habit of getting over-booked (is there a 12 step program for this problem ;-)
Yes, but by the 6th step you can't afford to pay the assistants ;-)
-- anyway, I'm hoping we will be able to support a number of projects. Actually, I'm a little suprised there hasn't been more response to your post. I'm starting a discussion amoungst the moderators about how we want to organize to take this on.
I'm putting together a list of Boost.Build related projects that I would be willing to mentor. So if you want you can include me in that discussion :-) -- -- 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 Sun, 16 Apr 2006 11:12:51 -0500, Rene Rivera wrote
-- anyway, I'm hoping we will be able to support a number of projects. Actually, I'm a little suprised there hasn't been more response to your post. I'm starting a discussion amoungst the moderators about how we want to organize to take this on.
I'm putting together a list of Boost.Build related projects that I would be willing to mentor. So if you want you can include me in that discussion :-)
No reply from anyone yet, but we'll include you... In the meantime, I've seeded a Wiki page -- can you put your ideas there as a start? Jeff
On Sun, 16 Apr 2006 11:12:51 -0500, Rene Rivera wrote
Jeff Garland wrote:
I'm putting together a list of Boost.Build related projects that I would be willing to mentor. So if you want you can include me in that discussion :-)
To fast on the send...the wiki page is at: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer... Jeff
Jeff Garland wrote:
On Sun, 16 Apr 2006 11:12:51 -0500, Rene Rivera wrote
Jeff Garland wrote:
I'm putting together a list of Boost.Build related projects that I would be willing to mentor. So if you want you can include me in that discussion :-)
To fast on the send...the wiki page is at:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer...
Thanks :-) I added the two items I had so far, longer descriptions to follow soon. -- -- 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 4/16/06, Rene Rivera <grafik.list@redshift-software.com> wrote:
Jeff Garland wrote:
On Sun, 16 Apr 2006 11:40:07 +0200, Julio M. Merino Vidal wrote
On 4/15/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
We'll need to submit a request and such:
http://code.google.com/soc/mentorfaq.html So... I'm curious. Are you going to do it? :-)
Personally I'm thinking I would be smart not to take on another project. I have a cronic habit of getting over-booked (is there a 12 step program for this problem ;-)
Yes, but by the 6th step you can't afford to pay the assistants ;-)
-- anyway, I'm hoping we will be able to support a number of projects. Actually, I'm a little suprised there hasn't been more response to your post. I'm starting a discussion amoungst the moderators about how we want to organize to take this on.
I'm putting together a list of Boost.Build related projects that I would be willing to mentor. So if you want you can include me in that discussion :-)
Is this list what somebody (you?) put in the wiki? It'd be interesting to see who is available to mentor each item. Anyway, the "Configure" Boost.Build project caught my eye. Which could be the requirements for such a tool? I expect it'd need to run natively under Windows and Unix-based systems, right? Which language would it need to be written in? Maybe C++ is the obvious answer, but then there is a "bootstrapping" problem (you might need to configure the tool to build the tool successfully). Just saying this because it'd be good to have as much details as possible for each proposed project. And... would someone be willing to mentor a Boost.Process library? :-) Cheers, -- Julio M. Merino Vidal <jmmv84@gmail.com> The Julipedia - http://julipedia.blogspot.com/
Julio M. Merino Vidal wrote:
On 4/16/06, Rene Rivera <grafik.list@redshift-software.com> wrote:
Jeff Garland wrote:
On 4/15/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
We'll need to submit a request and such:
http://code.google.com/soc/mentorfaq.html So... I'm curious. Are you going to do it? :-) Personally I'm thinking I would be smart not to take on another project. I have a cronic habit of getting over-booked (is there a 12 step program for
On Sun, 16 Apr 2006 11:40:07 +0200, Julio M. Merino Vidal wrote this problem ;-) Yes, but by the 6th step you can't afford to pay the assistants ;-)
-- anyway, I'm hoping we will be able to support a number of projects. Actually, I'm a little suprised there hasn't been more response to your post. I'm starting a discussion amoungst the moderators about how we want to organize to take this on. I'm putting together a list of Boost.Build related projects that I would be willing to mentor. So if you want you can include me in that discussion :-)
Is this list what somebody (you?) put in the wiki? It'd be interesting to see who is available to mentor each item.
I think you figured the answer to that one by now ;-) But I provisionally listed myself on those two as the mentor. The administrator has the final say on that though :-)
Anyway, the "Configure" Boost.Build project caught my eye. Which could be the requirements for such a tool?
I also added a few requirements to that one item. I'll expand the other one a bit later.
I expect it'd need to run natively under Windows and Unix-based systems, right? Which language would it need to be written in?
It's Boost.Build, so you'd have to read up on what I mean by that :-) Short answer it's the Jam interpreted language which is natively compiled cross-platform interpreter program with possible hooks into Python.
Maybe C++ is the obvious answer, but then there is a "bootstrapping" problem (you might need to configure the tool to build the tool successfully).
Boost.Jam already knows how to bootstrap itself. Boost.Jam would play the role that Bourne SH plus M4 play in Autoconf.
Just saying this because it'd be good to have as much details as possible for each proposed project.
Of course. It just takes time to add those details :-) And eventually they have to be added to the Google management website for SoC. -- -- 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 <grafik.list@redshift-software.com> wrote:
Julio M. Merino Vidal wrote:
Anyway, the "Configure" Boost.Build project caught my eye. Which could be the requirements for such a tool?
I also added a few requirements to that one item. I'll expand the other one a bit later.
Before you start, you should have a look at BuildSystem [1]. It is used as the configuration engine for PETSc [2], which runs on more platforms than you can shake a stick at. It is implemented in Python. The docs are a bit sketchy, and it still needs work for mere mortals to be able to use. In any case, I have implemented it for my software, which you can get with subversion at http://geodynamics.org/svn/cig/long/3D/Gale/trunk There is a configure.py script, but most of the meat is in the python/ subdirectory. Cheers, Walter Landry wlandry@ucsd.edu [1] http://sidl.bkbits.net:8080/BuildSystem [2] http://www-unix.mcs.anl.gov/petsc/petsc-as/
Walter Landry <wlandry@ucsd.edu> writes:
Rene Rivera <grafik.list@redshift-software.com> wrote:
Julio M. Merino Vidal wrote:
Anyway, the "Configure" Boost.Build project caught my eye. Which could be the requirements for such a tool?
I also added a few requirements to that one item. I'll expand the other one a bit later.
Before you start, you should have a look at BuildSystem [1]. It is used as the configuration engine for PETSc [2], which runs on more platforms than you can shake a stick at. It is implemented in Python. The docs are a bit sketchy, and it still needs work for mere mortals to be able to use. In any case, I have implemented it for my software, which you can get with subversion at
http://geodynamics.org/svn/cig/long/3D/Gale/trunk
There is a configure.py script, but most of the meat is in the python/ subdirectory.
Walter, I'm always very curious when you make this reference (you've mentioned this before, right? Sounds familiar) as to what you expect to happen. As you know, boost has a significant investment and momentum in designing and developing Boost.Build, we have an extensive test suite, and we even have fairly complete (if imperfect) documentation. Surely you recognize that it's unlikely anyone is going to look at a system whose "docs are a bit sketchy, and it still needs work for mere mortals to be able to use," determine that it really holds greater potential than everything we've developed and currently have planned, convince the other invested parties to change direction, etc? I am not 100% wedded to Boost.Build; if you've come up with something better than everything else out there, then we should talk about it, but you'd have to give us more to go on than a vague reference to some source code with little additional information other than some caveats. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> wrote:
I'm always very curious when you make this reference (you've mentioned this before, right? Sounds familiar)
This is the first time I mentioned this system. In the past I just wanted a configuration system of any kind. There is sort of one already [1], but now there seems to be talk of implementing something more ambitious. You can spend an eternity working on this problem. I would prefer if Boost got out of the business of build systems, and instead focused on just writing great libraries.
as to what you expect to happen. As you know, boost has a significant investment and momentum in designing and developing Boost.Build, we have an extensive test suite, and we even have fairly complete (if imperfect) documentation. Surely you recognize that it's unlikely anyone is going to look at a system whose "docs are a bit sketchy, and it still needs work for mere mortals to be able to use," determine that it really holds greater potential than everything we've developed and currently have planned, convince the other invested parties to change direction, etc?
I am not suggesting getting rid of Boost.Build entirely. BuildSystem would be used for configuration, and Boost.Build could still be used for building. I use BuildSystem with SCons. Petsc uses it with make. Cheers, Walter Landry wlandry@ucsd.edu [1] For example, I can not figure out how to get it to use g++-4.1 instead of the default g++ (which is 4.0). This is really unacceptable. It shouldn't take me more than 30 seconds to figure that out.
On 4/20/06, Walter Landry <wlandry@ucsd.edu> wrote: I am not suggesting getting rid of Boost.Build entirely. BuildSystem
would be used for configuration, and Boost.Build could still be used for building. I use BuildSystem with SCons. Petsc uses it with make.
How would introducing yet another tool into the build process help in any way? I think Boost.Config (header files) plays the same role BuildSystem does in this case, with no extra tools required. -- Caleb Epstein caleb dot epstein at gmail dot com
Walter Landry <wlandry@ucsd.edu> writes:
[1] For example, I can not figure out how to get it to use g++-4.1 instead of the default g++ (which is 4.0). This is really unacceptable. It shouldn't take me more than 30 seconds to figure that out.
Boost.Build v2: # ~/user-config.jam using gcc : : path/to/g++-4.1 ; makes g++-4.1 your default gcc. Of course you can also register your versions separately: using gcc : 4.0 : g++ ; using gcc : 4.1 : path/to/g++-4.1 ; couldn't be much easier. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Walter Landry <wlandry@ucsd.edu> writes:
[1] For example, I can not figure out how to get it to use g++-4.1 instead of the default g++ (which is 4.0). This is really unacceptable. It shouldn't take me more than 30 seconds to figure that out.
Boost.Build v2:
# ~/user-config.jam using gcc : : path/to/g++-4.1 ;
makes g++-4.1 your default gcc. Of course you can also register your versions separately:
using gcc : 4.0 : g++ ; using gcc : 4.1 : path/to/g++-4.1 ;
couldn't be much easier.
Well, to be honest, some simple python script, or python-style function with keyword-arguments calling conventions would be much more intuitive. I can't say that I would have thought of the above syntax readily, I have to admit. FWIW. Regards, Stefan
Stefan Seefeld wrote:
using gcc : 4.0 : g++ ; using gcc : 4.1 : path/to/g++-4.1 ;
couldn't be much easier.
Well, to be honest, some simple python script, or python-style function with keyword-arguments calling conventions would be much more intuitive.
If you're talking about syntax matters, then it's a beated horse. Are you willing to join the V2-to-Python porting effort?
I can't say that I would have thought of the above syntax readily, I have to admit. FWIW.
The above never caused any confusion with any user. Did you try to read V2 docs? - Volodya
Vladimir Prus wrote:
Stefan Seefeld wrote:
using gcc : 4.0 : g++ ; using gcc : 4.1 : path/to/g++-4.1 ;
couldn't be much easier.
Well, to be honest, some simple python script, or python-style function with keyword-arguments calling conventions would be much more intuitive.
If you're talking about syntax matters, then it's a beated horse. Are you willing to join the V2-to-Python porting effort?
Do you have any references where I can learn more about this ? I know we already talked about it in the past, but I have only a very vague idea about what it actually means.
I can't say that I would have thought of the above syntax readily, I have to admit. FWIW.
The above never caused any confusion with any user. Did you try to read V2 docs?
Yes. I'm not saying the language can't be learned, just that it isn't obvious, and (to me at least) as easy as David made it sound. Regards, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
I can't say that I would have thought of the above syntax readily, I have to admit. FWIW.
The above never caused any confusion with any user. Did you try to read V2 docs?
Yes. I'm not saying the language can't be learned, just that it isn't obvious, and (to me at least) as easy as David made it sound.
It's just as obvious as any other interface we might choose. Someone would have to read some documentation or see some examples before knowing what to do. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Friday 21 April 2006 17:07, Stefan Seefeld wrote:
Vladimir Prus wrote:
Stefan Seefeld wrote:
using gcc : 4.0 : g++ ; using gcc : 4.1 : path/to/g++-4.1 ;
couldn't be much easier.
Well, to be honest, some simple python script, or python-style function with keyword-arguments calling conventions would be much more intuitive.
If you're talking about syntax matters, then it's a beated horse. Are you willing to join the V2-to-Python porting effort?
Do you have any references where I can learn more about this ? I know we already talked about it in the past, but I have only a very vague idea about what it actually means.
The only thing I can point to is instructions for getting that port: https://zigzag.cs.msu.su/boost.build/wiki/PythonPort It's very early version, so don't expect much from it. Basically, the idea is to rewrite high-level part of Boost.Build, while retaining the underlying build engine and (initially), Jamfile syntax. After that, we can consider allowing Python build description files. - Volodya
Hi Volodya, Vladimir Prus wrote:
The only thing I can point to is instructions for getting that port:
That page mentions to "Get CVS version of Boost.Build V2". Is that part of the boost repository ? Or do I need to check out something else, too ?
It's very early version, so don't expect much from it. Basically, the idea is to rewrite high-level part of Boost.Build, while retaining the underlying build engine and (initially), Jamfile syntax. After that, we can consider allowing Python build description files.
Sounds good ! Regards, Stefan
David Abrahams <dave@boost-consulting.com> wrote:
Walter Landry <wlandry@ucsd.edu> writes:
[1] For example, I can not figure out how to get it to use g++-4.1 instead of the default g++ (which is 4.0). This is really unacceptable. It shouldn't take me more than 30 seconds to figure that out.
Boost.Build v2:
# ~/user-config.jam using gcc : : path/to/g++-4.1 ;
makes g++-4.1 your default gcc. Of course you can also register your versions separately:
using gcc : 4.0 : g++ ; using gcc : 4.1 : path/to/g++-4.1 ;
couldn't be much easier.
This does not do what I want. I want to be able to type a short command (like "make" or "bjam"), and have it build with the compiler I specified when I configured. So different directories would use different compilers. I configure once (with all sorts of esoteric commands and locations), but build many times. It also does not help that this is not at all like the instructions given on the webpage. The webpage says that I can run configure in libs/config and copy user.hpp to the right place. That does not work. It is made even more difficult to debug because bjam prints out unhelpful lines like gcc-C++-action bin/boost/libs/regex/build/libboost_regex.so/gcc/release/shared-linkable-true/threading-multi/cregex.o instead of the actual command that it is executing. "bjam --help" gives no clue about how to get the actual command. Cheers, Walter
[Moving to the Boost.Build list; that's where this belongs] Walter Landry <wlandry@ucsd.edu> writes:
David Abrahams <dave@boost-consulting.com> wrote:
Walter Landry <wlandry@ucsd.edu> writes:
[1] For example, I can not figure out how to get it to use g++-4.1 instead of the default g++ (which is 4.0). This is really unacceptable. It shouldn't take me more than 30 seconds to figure that out.
Boost.Build v2:
# ~/user-config.jam using gcc : : path/to/g++-4.1 ;
makes g++-4.1 your default gcc. Of course you can also register your versions separately:
using gcc : 4.0 : g++ ; using gcc : 4.1 : path/to/g++-4.1 ;
couldn't be much easier.
This does not do what I want. I want to be able to type a short command (like "make" or "bjam"), and have it build with the compiler I specified when I configured.
It absolutely does do that.
So different directories would use different compilers. I configure once (with all sorts of esoteric commands and locations), but build many times.
Oh, you want per-directory sticky selection of default toolset. That's an interesting idea, and probably easy to add.
It also does not help that this is not at all like the instructions given on the webpage. The webpage says that I can run configure in libs/config and copy user.hpp to the right place.
Wow, you're pretty confused I think. "The webpage" you're looking at has nothing to do with Boost.Build. John created a configure script to help with the deduction of #defines for the Boost.Config library. That's all it does, and that's all it's supposed to do. This whole thing predates Boost.Build by some considerable time (years, I think). Whatever it is that caused you to be confused about that should be fixed in the documentation. Maybe you can make some useful suggestions; I think I'm too close to it. On the other hand, you can get a working *nix configure/make/make install script for all of boost at http://www.boost-consulting.com/boost/configure. It will go out at the top level of the next release.
That does not work.
What, specifically, do you mean when you say that?
It is made even more difficult to debug because bjam prints out unhelpful lines like
gcc-C++-action bin/boost/libs/regex/build/libboost_regex.so/gcc/release/shared-linkable-true/threading-multi/cregex.o
instead of the actual command that it is executing. "bjam --help" gives no clue about how to get the actual command.
Works for me (using BBv2, v1 is about to be retired): %bjam --help Configuration help: Configuration file at /usr/home/dave/user-config.jam This file is used to configure your Boost.Build installation. Please read the user manual to find out where to put it. Available Help: These are the available options for obtaining documentation. Some options have additional instructions on how to get more detailed information. Multiple options are allowed and sometimes required. For example, the options that configure the help system still require a regular help request option for any output to be generated. * --help; This help message. * --help-usage; How to invoke 'bjam.' * --help-all; Brief information on available modules. * --help <module-name>; Get information about a module. * --help-options; Options for controlling the help display. * --help-output <type>; The type of output to genetare. 'console is formated text echoed to the console (the default);' 'text is formated text appended to the output file;' 'html is HTML output to the file.' * --help-output-file <file>; The file to output the documentation. ...found 1 target... %bjam --help-usage Boost.Jam Usage: bjam [ options... ] targets... * -a; Build all targets, even if they are current. * -fx; Read 'x' as the Jamfile for building instead of searching for the Boost.Build system. * -jx; Run up to 'x' commands concurrently. * -n; Do not execute build commands. Instead print out the commands as they would be executed if building. * -ox; Write the build commands to the file 'x'. * -q; Quit as soon as the build of a target fails. Specifying this prevents the attempt of building as many targets as possible regardless of failures. * -sx=y; Sets a Jam variable 'x' to the value 'y', overriding any value that variable would have from the environment. * -tx; Rebuild the target 'x', even if it is up-to-date. * -v; Display the version of bjam. * --x; Option 'x' is ignored but considered and option. The option is then available from the 'ARGV' variable. * -dn; Enables output of diagnostic messages. The debug level 'n' and all below it are enabled by this option. * -d+n; Enables output of diagnostic messages. Only the output for debug level 'n' is enabled. Debug Levels: Each debug level shows a different set of information. Usually with the higher levels producing more verbose information. The following levels are supported: * 0; Turn off all diagnostic output. Only errors are reported. * 1; Show the actions taken for building targets, as they are executed. * 2; Show quiet actions and display all action text, as they are executed. * 3; Show dependency analysis, and target/source timestamps/paths. * 4; Show arguments of shell invocations. * 5; Show rule invocations and variable expansions. * 6; Show directory/header file/archive scans, and attempts at binding to targets. * 7; Show variable settings. * 8; Show variable fetches, variable expansions, and evaluation of 'if' expressions. * 9; Show variable manipulation, scanner tokens, and memory usage. * 10; Show execution times for rules. * 11; Show parsing progress of Jamfiles. * 12; Show graph for target dependencies. * 13; Show changes in target status (fate). That's -d+5. It seems as though it's very difficult to satisfy anybody w.r.t. the output of a Build/Install system. Several people just wanted a progress indicator that was otherwise silent, and for a while I was convinced that would be best, but was about to change the default and many experienced Boost.Build users got very upset about it. Many others didn't like the idea of showing the full text of the build actions by default. Apparently the current output is perfect for many people. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Walter Landry wrote:
David Abrahams <dave@boost-consulting.com> wrote:
I'm always very curious when you make this reference (you've mentioned this before, right? Sounds familiar)
This is the first time I mentioned this system. In the past I just wanted a configuration system of any kind. There is sort of one already [1], but now there seems to be talk of implementing something more ambitious. You can spend an eternity working on this problem. I would prefer if Boost got out of the business of build systems, and instead focused on just writing great libraries.
As I allude to in the intro to the boost.build section of the SoC wiki page, I personally think writing great libraries isn't just about writing the code for those libraries. The tools one uses, and the documentation one creates is much of the time more important. If just for the plain reason that having good tools allows one to concentrate more on the libraries. As a mentor for Computer Science students I would think that the development process is the key point of SoC. The resulting code is just an excuse to get students acclimated to working in Open Source development process. (Yes I'm intentionally framing this only within the SoC.) Which [1] are you referring to?
I am not suggesting getting rid of Boost.Build entirely. BuildSystem would be used for configuration, and Boost.Build could still be used for building. I use BuildSystem with SCons. Petsc uses it with make.
That's fine... But it's hard to respond to your suggestion given that I wasn't able to figure out where and what this "BuildSystem" does. Trully I looked around in the code references you pointed out and it is just not followable. As for using it to "solve" the SoC project I would be open to a Python solution. Just as long as it integrates transparently with the Boost.Build structure. Specifically that we can create configured output files as targets within BBv2 for whatever the build variant specifications is requested within the various builds. More likely I would expect the student to have to heavily modify any outside source and of course heavily document that code. PS. Just because someone else has already done it doesn't mean it isn't worthwhile to redo. After all that "it's already done we'll just hack it a bit" attitude is why Autoconf is still in use. -- -- 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 <grafik.list@redshift-software.com> wrote:
As I allude to in the intro to the boost.build section of the SoC wiki page, I personally think writing great libraries isn't just about writing the code for those libraries. The tools one uses, and the documentation one creates is much of the time more important. If just for the plain reason that having good tools allows one to concentrate more on the libraries. As a mentor for Computer Science students I would think that the development process is the key point of SoC. The resulting code is just an excuse to get students acclimated to working in Open Source development process. (Yes I'm intentionally framing this only within the SoC.)
You could use this rationale to have boost work on compilers, linkers, operating systems, and hardware. There are other groups that concentrate on making good build tools. Boost does not exist because people wanted better build tools. If you are interested in build tools, then by all means join those other groups. You can even use Boost as a testbed. But I don't think it is good to have boosters work on it to the point where it distracts away from Boost's raison d'etre: making good C++ libraries. Cheers, Walter
Walter Landry wrote:
Rene Rivera <grafik.list@redshift-software.com> wrote:
As I allude to in the intro to the boost.build section of the SoC wiki page, I personally think writing great libraries isn't just about writing the code for those libraries. The tools one uses, and the documentation one creates is much of the time more important. If just for the plain reason that having good tools allows one to concentrate more on the libraries. As a mentor for Computer Science students I would think that the development process is the key point of SoC. The resulting code is just an excuse to get students acclimated to working in Open Source development process. (Yes I'm intentionally framing this only within the SoC.)
You could use this rationale to have boost work on compilers, linkers, operating systems, and hardware.
Yes I could. And don't think none of those are not of interest to me :-) And some number in the Boost community actively work on such things.
There are other groups that concentrate on making good build tools.
True, and we;ve thought about switching and/or collaborating with such groups. For example Scons.
Boost does not exist because people wanted better build tools.
True, it exists to make better C++ libraries. But you can't have libraries without tools.
If you are interested in build tools, then by all means join those other groups. You can even use Boost as a testbed. But I don't think it is good to have boosters work on it to the point where it distracts away from Boost's raison d'etre: making good C++ libraries.
Why do you think it distracts away from the libraries? If some of us have the time and inclination to make some of the tools Boost developers need better doesn't that benefit everyone? We get to work on things that interest us, and sometimes have our own needs for, and Boost and other developers get better tools. Yes, I'm entirely open to using other groups efforts, and I am genuinely interested in the tool you pointed us to. If I could only get some reasonable documentation for it I could then evaluate it. -- -- 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:
Walter Landry wrote:
Rene Rivera <grafik.list@redshift-software.com> wrote:
As I allude to in the intro to the boost.build section of the SoC wiki page, I personally think writing great libraries isn't just about writing the code for those libraries. The tools one uses, and the documentation one creates is much of the time more important. If just for the plain reason that having good tools allows one to concentrate more on the libraries. As a mentor for Computer Science students I would think that the development process is the key point of SoC. The resulting code is just an excuse to get students acclimated to working in Open Source development process. (Yes I'm intentionally framing this only within the SoC.) You could use this rationale to have boost work on compilers, linkers, operating systems, and hardware.
Yes I could. And don't think none of those are not of interest to me :-) And some number in the Boost community actively work on such things.
There are other groups that concentrate on making good build tools.
True, and we;ve thought about switching and/or collaborating with such groups. For example Scons.
...snip....
Boost does not exist because people wanted better build tools.
True, it exists to make better C++ libraries. But you can't have libraries without tools.
If you are interested in build tools, then by all means join those other groups. You can even use Boost as a testbed. But I don't think it is good to have boosters work on it to the point where it distracts away from Boost's raison d'etre: making good C++ libraries.
Why do you think it distracts away from the libraries? If some of us have the time and inclination to make some of the tools Boost developers need better doesn't that benefit everyone? We get to work on things that interest us, and sometimes have our own needs for, and Boost and other developers get better tools.
Yes, I'm entirely open to using other groups efforts, and I am genuinely interested in the tool you pointed us to. If I could only get some reasonable documentation for it I could then evaluate it.
Let me preface by saying that I don't read the Boost.Build list, so I haven't paid much attention to what has and hasn't been considered over the last few years. But frankly, it seems to me that the bjam/boost.build decision was made 5 years (or more) ago and never really revisited since. And that's fine, from my vantage -- boost.build has mostly just worked -- it does what I need and then some. Sure, new folks are sometimes confused, but that's really due to a lack of binary packaging and some mediocre documentation -- not some fundamental issue with Boost.Build. As I recall during the original build system discussions I was a proponent of a very different approach. That is, instead of trying to create a cross-platform fully ported 'build system', you use a 'make file generator' tool. In this approach, the developer specifies something very much like the current Jamfiles -- a list of files to compile, and various options. Then a tool applies platform-compiler specific settings and generates a platform specific 'make files' that can use platform specific tools. The makefile generation approach has different advantages and disadvantages than the current system. For example, the big advantage of generated makefiles for 'single platform users' is that they use whatever the native build system is -- Makefiles on *nix -- solution/project files on windows. The nice effect being that no training is necessary to explain how things work. The downside is that for Boost library developers on multiple platforms it's harder because instead of having to understand one system, you have to deal with different build systems. And it also complicates packaging because you either deliver all the makefiles for every platform, make the user generate them, or have platform specific distributions. But if you want to run the debugger on Windows, there's no substitute for having a native project file. At the time that the Boost.Build approach was pursued, there weren't many good options in the makefile generation space (basically Imake). Now, however, there is MPC -- Make Project Creator -- which is another open source product that serves as the build system for another widely ported C++ project: ACE/TAO. Kevin Heifner of OCI posted about this tool a couple months back: http://lists.boost.org/Archives/boost/2006/02/100967.php MPC is a serious tool with complete and professionally done docs (http://downloads.ociweb.com/MPC/MakeProjectCreator.pdf). MPC is heavily used for both open source and industrial C++ projects on more platforms/compilers than Boost currently supports. It's what I use for my own personal projects and I've also used it successfully on large industrial C++ projects. MPC could be a very different direction for Boost. Kevin didn't try to sell it as a replacement for bjam, only as an augmentation, but I believe we could adopt MPC and dump Boost.Build. But even after saying all that, I seriously doubt we can consider going away from Boost.Build. All change comes with a price -- people have to study it, learn it, write docs, rewrite regression test scripts, etc. It probably takes as much or more effort away from library development to switch the build system than as it does to keep improving the current system. So my advice would be for folks that have issues with Boost.Build is to get them documented and work with the team on getting them resolved. 98% of the issues I see are documentation and not functionality. Jeff
Jeff Garland <jeff@crystalclearsoftware.com> writes:
Let me preface by saying that I don't read the Boost.Build list, so I haven't paid much attention to what has and hasn't been considered over the last few years.
[cross-posting there; IMO you should really follow up on that list and read it on GMane or via the web if you don't want it in your INBOX]
But frankly, it seems to me that the bjam/boost.build decision was made 5 years (or more) ago and never really revisited since.
No, it gets revisited about every 6 months, when somebody complains that they don't like our choice. We talk about the alternatives and how well they'd serve Boost's needs, but have not (so far) come up with a different answer. Also, the move to develop BBv2 represents a substatial "revisiting" of the BBv1 decision and how well it is playing out for us. That project began... oh, geez, about 4 years ago, in 2002. So I guess we realized by then that BBv1 had some shortcomings that we wanted to address.
And that's fine, from my vantage -- boost.build has mostly just worked -- it does what I need and then some. Sure, new folks are sometimes confused, but that's really due to a lack of binary packaging and some mediocre documentation -- not some fundamental issue with Boost.Build.
Yes; I've had a complete doc rewrite in my queue for some time now. I'm eager to get to it.
As I recall during the original build system discussions I was a proponent of a very different approach. That is, instead of trying to create a cross-platform fully ported 'build system', you use a 'make file generator' tool. In this approach, the developer specifies something very much like the current Jamfiles -- a list of files to compile, and various options. Then a tool applies platform-compiler specific settings and generates a platform specific 'make files' that can use platform specific tools.
The makefile generation approach has different advantages and disadvantages than the current system. For example, the big advantage of generated makefiles for 'single platform users' is that they use whatever the native build system is -- Makefiles on *nix -- solution/project files on windows.
The nice effect being that no training is necessary to explain how things work.
Explain to whom? Certainly somebody would need to understand how to use the tool to generate these makefiles. The other upside, usually, is build/update speed. Because the makefile expresses build instructions at an extremely low level of abstraction, there's no risk of paying an abstraction penalty for BB's high level project descriptions. However, then you need to decide somehow when to regenerate the makefiles.
The downside is that for Boost library developers on multiple platforms it's harder because instead of having to understand one system, you have to deal with different build systems. And it also complicates packaging because you either deliver all the makefiles for every platform, make the user generate them, or have platform specific distributions. But if you want to run the debugger on Windows, there's no substitute for having a native project file.
Sure there is! I run my Boost tests with bjam ... --debugger="devenv /debugexe" and it launches the test inside the Visual Studio debugger.
At the time that the Boost.Build approach was pursued, there weren't many good options in the makefile generation space (basically Imake). Now, however, there is MPC -- Make Project Creator -- which is another open source product that serves as the build system for another widely ported C++ project: ACE/TAO. Kevin Heifner of OCI posted about this tool a couple months back:
http://lists.boost.org/Archives/boost/2006/02/100967.php
MPC is a serious tool with complete and professionally done docs (http://downloads.ociweb.com/MPC/MakeProjectCreator.pdf).
Note: this document is only 48 pages long; it's worth a read if anyone is interested in knowing more.
MPC is heavily used for both open source and industrial C++ projects on more platforms/compilers than Boost currently supports. It's what I use for my own personal projects and I've also used it successfully on large industrial C++ projects. MPC could be a very different direction for Boost. Kevin didn't try to sell it as a replacement for bjam, only as an augmentation, but I believe we could adopt MPC and dump Boost.Build.
Have you done an extensive analysis of our requirements, or is this a less-researched impression? BTW, I think using BB to generate MPC project specifications
But even after saying all that, I seriously doubt we can consider going away from Boost.Build. All change comes with a price -- people have to study it, learn it, write docs, rewrite regression test scripts, etc. It probably takes as much or more effort away from library development to switch the build system than as it does to keep improving the current system. So my advice would be for folks that have issues with Boost.Build is to get them documented and work with the team on getting them resolved. 98% of the issues I see are documentation and not functionality.
Agreed. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave <at> boo...com> writes:
Jeff Garland <jeff <at> cry...com> writes:
For example, the big advantage of generated makefiles for 'single platform users' is that they use whatever the native build system is -- Makefiles on *nix -- solution/project files on windows.
The nice effect being that no training is necessary to explain how things work.
Explain to whom?
For most Windows developers! Every time a Windows developer wants to use Boost for the first time he hits the wall with his head when he realize that he must use something else than solution/project files. And in this case it is not even make (or nmake) that needs to be run, but something called bjam, which he probably have never heard of.
The downside is that for Boost library developers on multiple platforms it's harder because instead of having to understand one system, you have to deal with different build systems. And it also complicates packaging because you either deliver all the makefiles for every platform, make the user generate them, or have platform specific distributions.
Yes, this must be a huge downside for the Boost library developers! I guess that this is the key point for sticking with BB? But what is most important; to make users of the Boost libraries happier by providing Boost in a format that they can use directly without banging their heads, or to make the library developers' life happier? On this list, I think the answer is obvious ;-)
But if you want to run the debugger on Windows, there's no substitute for having a native project file.
Sure there is! I run my Boost tests with
bjam ... --debugger="devenv /debugexe"
and it launches the test inside the Visual Studio debugger.
This is nice! But a Windows developer new to BB, who has not bothered to RTFM, would not know this. But even if you are not new to BB, as in Jeff's case, you may not know this...
MPC is heavily used for both open source and industrial C++ projects on more platforms/compilers than Boost currently supports. It's what I use for my own personal projects and I've also used it successfully on large industrial C++ projects. MPC could be a very different direction for Boost. Kevin didn't try to sell it as a replacement for bjam, only as an augmentation, but I believe we could adopt MPC and dump Boost.Build.
This would be great for me as a Boost library end-user!
But even after saying all that, I seriously doubt we can consider going away from Boost.Build.
Yes, it is way easier for Boost library developers to stick with BB. I understand this. But again, since there obviously is an interest in "selling" Boost (I'm thinking about the new web page style among other things) a switch from BB to platform specific distributions would IMHO certainly help selling Boost! FWIW... /Rune
Rune <rune.sune@yahoo.com> writes:
David Abrahams <dave <at> boo...com> writes:
Jeff Garland <jeff <at> cry...com> writes:
For example, the big advantage of generated makefiles for 'single platform users' is that they use whatever the native build system is -- Makefiles on *nix -- solution/project files on windows.
The nice effect being that no training is necessary to explain how things work.
Explain to whom?
For most Windows developers! Every time a Windows developer wants to use Boost for the first time he hits the wall with his head when he realize that he must use something else than solution/project files. And in this case it is not even make (or nmake) that needs to be run, but something called bjam, which he probably have never heard of.
Fortunately that will be a non-issue for most windows developers Real Soon Now (like, this afternoon, if I have time to make the posting). Boost Consulting will be hosting a graphical windows installer for MSVC++ 7.1 and 8.0.
The downside is that for Boost library developers on multiple platforms it's harder because instead of having to understand one system, you have to deal with different build systems. And it also complicates packaging because you either deliver all the makefiles for every platform, make the user generate them, or have platform specific distributions.
Yes, this must be a huge downside for the Boost library developers! I guess that this is the key point for sticking with BB?
Not exactly.
But what is most important; to make users of the Boost libraries happier by providing Boost in a format that they can use directly without banging their heads, or to make the library developers' life happier? On this list, I think the answer is obvious ;-)
You misunderstand; it's not about developer happiness. If the developers aren't _effective_, how happy can the users be? Before Boost.Build we had, in the worst case, a classic NxMxL problem: N libraries times M compilers times L standard libraries = NxMxL separate build descriptions. That was very bad for leveraging expertise of library authors and platform experts. Now (with BBv2) we have: one toolset file per compiler family, one per replacement standard library, and one build description per library.
But if you want to run the debugger on Windows, there's no substitute for having a native project file.
Sure there is! I run my Boost tests with
bjam ... --debugger="devenv /debugexe"
and it launches the test inside the Visual Studio debugger.
This is nice! But a Windows developer new to BB, who has not bothered to RTFM, would not know this. But even if you are not new to BB, as in Jeff's case, you may not know this...
What's your point?
MPC is heavily used for both open source and industrial C++ projects on more platforms/compilers than Boost currently supports. It's what I use for my own personal projects and I've also used it successfully on large industrial C++ projects. MPC could be a very different direction for Boost. Kevin didn't try to sell it as a replacement for bjam, only as an augmentation, but I believe we could adopt MPC and dump Boost.Build.
This would be great for me as a Boost library end-user!
How can you be sure?
But even after saying all that, I seriously doubt we can consider going away from Boost.Build.
Yes, it is way easier for Boost library developers to stick with BB. I understand this. But again, since there obviously is an interest in "selling" Boost (I'm thinking about the new web page style among other things) a switch from BB to platform specific distributions would IMHO certainly help selling Boost!
That's what the installer is all about. -- Dave Abrahams Boost Consulting www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
Fortunately that will be a non-issue for most windows developers Real Soon Now (like, this afternoon, if I have time to make the posting). Boost Consulting will be hosting a graphical windows installer for MSVC++ 7.1 and 8.0.
Great news!
But what is most important; to make users of the Boost libraries happier by providing Boost in a format that they can use directly without banging their heads, or to make the library developers' life happier? On this list, I think the answer is obvious ;-)
You misunderstand; it's not about developer happiness. If the developers aren't _effective_, how happy can the users be? Before Boost.Build we had, in the worst case, a classic NxMxL problem: N libraries times M compilers times L standard libraries = NxMxL separate build descriptions. That was very bad for leveraging expertise of library authors and platform experts.
Yes, I understand this.
Now (with BBv2) we have: one toolset file per compiler family, one per replacement standard library, and one build description per library.
I'm sure this is very nice for Boost library developers.
But if you want to run the debugger on Windows, there's no substitute for having a native project file.
Sure there is! I run my Boost tests with
bjam ... --debugger="devenv /debugexe"
and it launches the test inside the Visual Studio debugger.
This is nice! But a Windows developer new to BB, who has not bothered to RTFM, would not know this. But even if you are not new to BB, as in Jeff's case, you may not know this...
What's your point?
My point is that the ladder to climb for a Boost newbie end-user is "unnecessary" high. That is, it is unnecessary high from the end-users viewpoint. If the newbie only had the usual interface towards the development project, i.e. make- or dsp-files, he could focus on his key problems instead of having to grasp all of BB. I have climbed this ladder myself and it is not that fun. And I'm still climbing btw - but it is probably just me ;-)
MPC is heavily used for both open source and industrial C++ projects on more platforms/compilers than Boost currently supports. It's what I use for my own personal projects and I've also used it successfully on large industrial C++ projects. MPC could be a very different direction for Boost. Kevin didn't try to sell it as a replacement for bjam, only as an augmentation, but I believe we could adopt MPC and dump Boost.Build.
This would be great for me as a Boost library end-user!
How can you be sure?
You are right, I'm not sure since I have no experience of MPC. And I have seen silver bullets in disguise before... But since MPC has its roots in ACE/TAO I'm pretty sure that it is worth having a look at.
But even after saying all that, I seriously doubt we can consider going away from Boost.Build.
Yes, it is way easier for Boost library developers to stick with BB. I understand this. But again, since there obviously is an interest in "selling" Boost (I'm thinking about the new web page style among other things) a switch from BB to platform specific distributions would IMHO certainly help selling Boost!
That's what the installer is all about.
Again, great news! /Rune __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Rune Sune <rune.sune@yahoo.com> writes:
--- David Abrahams <dave@boost-consulting.com> wrote:
Fortunately that will be a non-issue for most windows developers Real Soon Now (like, this afternoon, if I have time to make the posting). Boost Consulting will be hosting a graphical windows installer for MSVC++ 7.1 and 8.0.
Great news!
But what is most important; to make users of the Boost libraries happier by providing Boost in a format that they can use directly without banging their heads, or to make the library developers' life happier? On this list, I think the answer is obvious ;-)
You misunderstand; it's not about developer happiness. If the developers aren't _effective_, how happy can the users be? Before Boost.Build we had, in the worst case, a classic NxMxL problem: N libraries times M compilers times L standard libraries = NxMxL separate build descriptions. That was very bad for leveraging expertise of library authors and platform experts.
Yes, I understand this.
Now (with BBv2) we have: one toolset file per compiler family, one per replacement standard library, and one build description per library.
I'm sure this is very nice for Boost library developers.
That's not the point. Now users get straightforward build instructions rather than being told to add the source files to their projects and define this-and-that, they have shared libraries uniformly, we have a reasonably robust and efficient testing system, so users get more reliable and portable libraries. The other lack-of-system leaves developers without the means to do a good job, which means that users get worse service.
This is nice! But a Windows developer new to BB, who has not bothered to RTFM, would not know this. But even if you are not new to BB, as in Jeff's case, you may not know this...
What's your point?
My point is that the ladder to climb for a Boost newbie end-user is "unnecessary" high.
Yes, we know.
That is, it is unnecessary high from the end-users viewpoint. If the newbie only had the usual interface towards the development project, i.e. make- or dsp-files, he could focus on his key problems instead of having to grasp all of BB.
The user doesn't have to grasp all of BB. We just need improved getting started directions, which I am writing. Only a very small amount of grasping is required. If you want make- or dsp- files (note that dsp files are platform *and* compiler-specific), figure out a way to generate them from within Boost.Build, and we'll include them.
MPC is heavily used for both open source and industrial C++ projects on more platforms/compilers than Boost currently supports. It's what I use for my own personal projects and I've also used it successfully on large industrial C++ projects. MPC could be a very different direction for Boost. Kevin didn't try to sell it as a replacement for bjam, only as an augmentation, but I believe we could adopt MPC and dump Boost.Build.
This would be great for me as a Boost library end-user!
How can you be sure?
You are right, I'm not sure since I have no experience of MPC. And I have seen silver bullets in disguise before... But since MPC has its roots in ACE/TAO I'm pretty sure that it is worth having a look at.
That's a more appropriate response, IMO, than jumping on a "dump BB and use MPC" bandwagon. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rune Sune <rune.sune@yahoo.com> writes:
--- David Abrahams <dave@boost-consulting.com> wrote:
That is, it is unnecessary high from the end-users viewpoint. If the newbie only had the usual interface towards the development project, i.e. make- or dsp-files, he could focus on his key problems instead of having to grasp all of BB.
The user doesn't have to grasp all of BB. We just need improved getting started directions, which I am writing. Only a very small amount of grasping is required.
If you want make- or dsp- files (note that dsp files are platform *and* compiler-specific), figure out a way to generate them from within Boost.Build, and we'll include them.
Which is what the second SoC Boost.Build project I'm willing to mentor is about. -- -- 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" <grafik.list@redshift-software.com> wrote
David Abrahams wrote:
Rune Sune <rune.sune@yahoo.com> writes:
--- David Abrahams <dave@boost-consulting.com> wrote:
That is, it is unnecessary high from the end-users viewpoint. If the newbie only had the usual interface towards the development project, i.e. make- or dsp-files, he could focus on his key problems instead of having to grasp all of BB.
The user doesn't have to grasp all of BB. We just need improved getting started directions, which I am writing. Only a very small amount of grasping is required.
If you want make- or dsp- files (note that dsp files are platform *and* compiler-specific), figure out a way to generate them from within Boost.Build, and we'll include them.
Which is what the second SoC Boost.Build project I'm willing to mentor is about.
I am sorry, although I can probably be qualified as a Windows developer, I don't understand what dsp files have to do with building Boost... I can see two equaly acceptable (from the user's point of view) options of building Boost: 1) user gets ready to use binaries for his platform as a part of some sort of InstallShield-like setup process; 2) user gets some script file, that he runs with some parameters, and gets binaries as a result. As a (less convenient) altenative, this can be a set of commands to run, but the step-by-step instructions what to do (and what to expect, and what can go wrong) should be located at the same place, and no previous knowledge should be assumed (other than general OS knowledge). So, where do dsp files belong here? Regards, Arkadiy
On Apr 20, 2006, at 5:38 PM, Walter Landry wrote:
David Abrahams <dave@boost-consulting.com> wrote:
as to what you expect to happen. As you know, boost has a significant investment and momentum in designing and developing Boost.Build, we have an extensive test suite, and we even have fairly complete (if imperfect) documentation. Surely you recognize that it's unlikely anyone is going to look at a system whose "docs are a bit sketchy, and it still needs work for mere mortals to be able to use," determine that it really holds greater potential than everything we've developed and currently have planned, convince the other invested parties to change direction, etc?
I am not suggesting getting rid of Boost.Build entirely. BuildSystem would be used for configuration, and Boost.Build could still be used for building. I use BuildSystem with SCons. Petsc uses it with make.
If you're interested, I could send you a Jamfile we use for building Petsc/2.2.0a. -- Noel Belcourt
Walter Landry wrote:
as to what you expect to happen. As you know, boost has a significant investment and momentum in designing and developing Boost.Build, we have an extensive test suite, and we even have fairly complete (if imperfect) documentation. Surely you recognize that it's unlikely anyone is going to look at a system whose "docs are a bit sketchy, and it still needs work for mere mortals to be able to use," determine that it really holds greater potential than everything we've developed and currently have planned, convince the other invested parties to change direction, etc?
I am not suggesting getting rid of Boost.Build entirely. BuildSystem would be used for configuration, and Boost.Build could still be used for building. I use BuildSystem with SCons. Petsc uses it with make.
We (Boost.Build developers) are in fact very interested in a configure system. However, like Dave, I seem to miss the point of your post. Are you suggesting that we take your BuildSystem package and use it as basis for a configure solution for Boost.Build. Then, can you join us at Boost.Build mailing list (http://lists.boost.org/mailman/listinfo.cgi/boost-build), and give some more details about how your configure system works. Even rough outline is better than having to look at code that seem to lack any overview comments. Are you suggesting that we borrow some ideas from your solution? Then can you tell what are the most important ideas? Are you suggesting that we take your configure solution as-is, and apply to Boost? Then maybe you can write a small example? Looking at the configure.py you've linked, I don't see any checking for external libraries or headers, or something like that. - Volodya
Vladimir Prus <ghost@cs.msu.su> wrote:
Walter Landry wrote: We (Boost.Build developers) are in fact very interested in a configure system. However, like Dave, I seem to miss the point of your post.
Are you suggesting that we take your BuildSystem package and use it as basis for a configure solution for Boost.Build. Then, can you join us at Boost.Build mailing list (http://lists.boost.org/mailman/listinfo.cgi/boost-build), and give some more details about how your configure system works. Even rough outline is better than having to look at code that seem to lack any overview comments.
This is what I am suggesting. I will follow up on that list. Cheers, Walter
On Sun, Apr 16, 2006 at 08:42:56AM -0700, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
On Sun, 16 Apr 2006 11:40:07 +0200, Julio M. Merino Vidal wrote
So... I'm curious. Are you going to do it? :-)
Personally I'm thinking I would be smart not to take on another project. I have a cronic habit of getting over-booked (is there a 12 step program for this problem ;-) -- anyway, I'm hoping we will be able to support a number of projects. Actually, I'm a little suprised there hasn't been more response to your post. I'm starting a discussion amoungst the moderators about how we want to organize to take this on.
I hestitated, because I wasnt sure if I can claim to be part of the boost project. Nonetheless I would like to support students to finish a boost project within soc. I am sure I can dedicate about an hour per day for mentoring a student. Regards Andreas Pokorny
On 4/16/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
On Sun, 16 Apr 2006 11:40:07 +0200, Julio M. Merino Vidal wrote
On 4/15/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
for example) following the advice of people from this list.
I don't think the mentoring can be as general as 'people from the list'. We need to have specific people/organizations identified.
Sure not. Some specific mentors (one, two) would need to be specified for each project. But they could ask the students to post their questions in the open (that is, in this list) for wider discussion. That's why I said "people from this list".
Ok, but I don't think that works in general. Having been a student mentor a couple times in other contexts, it requires a certain amount of adminstrative and other guidance that I don't think can rightly come from the Boost list. For review of technical approaches and other questions the list would be fine.
Agreed.
We'll need to submit a request and such:
So... I'm curious. Are you going to do it? :-)
Personally I'm thinking I would be smart not to take on another project. I have a cronic habit of getting over-booked (is there a 12 step program for this problem ;-) -- anyway, I'm hoping we will be able to support a number of projects. Actually, I'm a little suprised there hasn't been more response to your post. I'm starting a discussion amoungst the moderators about how we want to organize to take this on.
Excellent! I'm certainly looking forward to it. Thanks, -- Julio M. Merino Vidal <jmmv84@gmail.com> The Julipedia - http://julipedia.blogspot.com/
Hello, Boost (http://www.boost.org) would like to participate as a mentoring organization in Google's Summer of Code program. Thank you for considering our application, -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 4/20/06, David Abrahams <dave@boost-consulting.com> wrote:
Hello,
Boost (http://www.boost.org) would like to participate as a mentoring organization in Google's Summer of Code program.
Thank you for considering our application,
I assume that this means that you already proposed Boost as a mentoring organization to Google, right? If not, I just wanted to point out that Google is only taking new applications until, at most, next Monday. See this: http://groups.google.com/group/Summer-Discuss-2006/browse_thread/thread/28d3... Cheers, -- Julio M. Merino Vidal <jmmv84@gmail.com> The Julipedia - http://julipedia.blogspot.com/
"Julio M. Merino Vidal" <jmmv84@gmail.com> writes:
On 4/20/06, David Abrahams <dave@boost-consulting.com> wrote:
Hello,
Boost (http://www.boost.org) would like to participate as a mentoring organization in Google's Summer of Code program.
Thank you for considering our application,
I assume that this means that you already proposed Boost as a mentoring organization to Google, right?
Not "already;" it was the same message Cc:'d here.
If not, I just wanted to point out that Google is only taking new applications until, at most, next Monday. See this:
http://groups.google.com/group/Summer-Discuss-2006/browse_thread/thread/28d3...
Which is why I went ahead and applied. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Fri, 14 Apr 2006 23:22:51 +0200, Julio M. Merino Vidal wrote
Hello,
Google has just announced that there will be a Summer of Code program this year. More information can be found here:
I'm posting this message in the hope that Boost joins as a mentoring organization. I think this was discussed the last year, but it was not on the final organizations list.
I think we were a little late getting orginzied on this -- we found out about it after the list of mentoring organizations were already closed.
Anyway, at least one of the mail threads started here:
http://lists.boost.org/Archives/boost/2005/05/87606.php
The goal could be to develop one of the "missing" libraries (those described in the Wiki,
Perhaps the unicode char/string support would be something that is doable if mentored appropriately.
I worry that most C++ libraries of any real importance require a level of experience that most students, even with an experienced Boost mentor to guide them, do not have. I also get the impression that the pool of students interested in developing C++ libraries will be rather limited, in part because of the way CS is taught these days. That said, we have a great many infrastructure projects that would be interesting and incredibly useful to have done -- documentation tools, website redesign, work on the build system, etc. -- and IMO some of these are likely to have a broader resonance. Maybe we should propose both kinds of project? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, 20 Apr 2006 09:12:21 -0700, David Abrahams wrote
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
I worry that most C++ libraries of any real importance require a level of experience that most students, even with an experienced Boost mentor to guide them, do not have.
I think that some rather well known Boosters were students (some still are) -- mostly PHD students mind you -- when they contributed a library. Julio V. is a student and has posted a particular interest in developing Boost.Process, which would be a highly useful and I think doable contribution. And if no one else wants to mentor him on this, I'll step up, but I think we should definately support this. Julio has already written quite alot about the scope, requirements, and issues for this library: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostProcess
I also get the impression that the pool of students interested in developing C++ libraries will be rather limited, in part because of the way CS is taught these days.
True, but we can probably only handle a few participants.
That said, we have a great many infrastructure projects that would be interesting and incredibly useful to have done -- documentation tools, website redesign, work on the build system, etc. -- and IMO some of these are likely to have a broader resonance.
Maybe we should propose both kinds of project?
For sure. Jeff
Jeff Garland wrote:
Julio V. is a student and has posted a particular interest in developing Boost.Process, which would be a highly useful and I think doable contribution. And if no one else wants to mentor him on this, I'll step up, but I think we should definately support this.
Are you suggesting a boost.mentor thing where one or two boosters volunteer to give more intimate comments for a library writer with less C++/Modern C++ experience? If so, I like the idea. -Thorsten
Thorsten Ottosen wrote:
Jeff Garland wrote:
Julio V. is a student and has posted a particular interest in developing Boost.Process, which would be a highly useful and I think doable contribution. And if no one else wants to mentor him on this, I'll step up, but I think we should definately support this.
Are you suggesting a boost.mentor thing where one or two boosters volunteer to give more intimate comments for a library writer with less C++/Modern C++ experience?
If so, I like the idea.
Yes, that's the what I'm saying. This is a required part of the summer of code -- we will have to identify particular Boosters to mentor the student developers. Jeff
Jeff Garland wrote:
Thorsten Ottosen wrote:
Jeff Garland wrote:
Julio V. is a student and has posted a particular interest in developing Boost.Process, which would be a highly useful and I think doable contribution. And if no one else wants to mentor him on this, I'll step up, but I think we should definately support this.
Are you suggesting a boost.mentor thing where one or two boosters volunteer to give more intimate comments for a library writer with less C++/Modern C++ experience?
If so, I like the idea.
Yes, that's the what I'm saying. This is a required part of the summer of code -- we will have to identify particular Boosters to mentor the student developers.
I was thinking in more general terms not just for SOC. -Thorsten
participants (14)
-
Andreas Pokorny -
Arkadiy Vertleyb -
Caleb Epstein -
David Abrahams -
Jeff Garland -
Julio M. Merino Vidal -
Noel Belcourt -
Rene Rivera -
Rune -
Rune Sune
-
Stefan Seefeld -
Thorsten Ottosen -
Vladimir Prus -
Walter Landry