Use of Other Languages in Boost Tools

Dear All Boosters, I am glad to read about Buildbot on the boost.devel group. It is definitely important for improving the regession test of Boost. However, A question comes into my mind then. As we all known, Boost is a pre-standard versatile C++ library for C++ programmers. Obviously all the Boost libraries are written in C++ themselves. However, for tools used in Boost (such as the Boost.Jam, Boost.Build, Boost.Book, etc.), the point is not clear, for they are not intended to be included or invoked by C++ programs directly. I saw that Buildbot is written almost completely in Python, for example. I am confused that shall we consist of writing all the Boost tools in C++? Or they can be written in any other languages such as shell scripts, Perl, Python, or even Java, C# or whatever convenient? I must declare that I am not a C++ purist or monomania.:) I have no intent to depreciate any of the languages other than C++, nor depreciate any of the valuable work done by Boosters. I just *wonder* what is the distinction between Boost libraries and tools exactly, and whether there is a rule we should follow for the development of Boost tools. For example, we now use the Boost.Jam and Boost.Build for our "official" build system. I believe that the goal of the Boost.Jam and Boost.Build is to provide a convenient, best and "standard" way for building C++ programs. However, as a *tool* (which is different from a *library*), one may not care about what language the Boost.Jam itself is written in. Nevertheless, suppose we were using Java Ant for building later, will it be acceptable? (of course, take Java Ant as an example here may be inappropriate.) The obvious two attitudes I can imagine are: (1) Prohibit *extensive* use of other programming languages in Boost tools, for example writing a complex tool in Python completely. (Convenient and small scripts are acceptable.) For we are establishing the Best Practice *in* C++ and *for* C++. In addition, the tools can be extensible and reusable with an API for C++ programmers as *developers* not just as *end-users*. (2) Allow extensive use of any convenient and reasonable programming languages in Boost tools. Maybe there should be a list for acceptable languages other than C++, for example shell scripts, Perl, Python, Ruby, etc. For they are just *tools*, not C++ *libraries*. They are just black boxes to C++ programmers, and we do *not* provide the tools as an extensible tool platform/framework with API for C++ developers/programmers for further extension or reuse. I tend to support (1), it seems to me more attractive. Boost.Wave is a good example in my opinion. It is both a practical *tool* related to C++ and an excellent extensible and reusable C++ *library*. I know that we should do the correct thing using the appropriate tool. There is no one language can rule them all.:) I am not crazy to imagine rewriting everything using C++. However, I do believe that we should concentrate on developing C++ libraries and *C++ tools* in our C++ Boost Project. As for Buildbot for example, maybe it is unwise to seek for a C++ replacement for it (for interpreted languages / scripts may be the correct choice), however I worry about that it has nothing to do with C++ or most Boost C++ programmers except that it is used by Boost Regression Test. Any comments are welcome, but NO flames or language-wars pls.:) Best regards, Allen

Allen <yaozhen@ustc.edu> writes:
I am confused that shall we consist of writing all the Boost tools in C++? Or they can be written in any other languages such as shell scripts, Perl, Python, or even Java, C# or whatever convenient?
I must declare that I am not a C++ purist or monomania.:) I have no intent to depreciate any of the languages other than C++, nor depreciate any of the valuable work done by Boosters. I just *wonder* what is the distinction between Boost libraries and tools exactly, and whether there is a rule we should follow for the development of Boost tools.
We don't need a special policy for Boost tools. They can be written in any language that is broadly understood. I'd prefer it if people stayed with languages *I* understand and write (C++, Python, not Perl), of course, but I suspect that many people feel that way so my list isn't special ;-> -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
Allen
-
David Abrahams