Hi, I would like to reiterate my concern about wave tool/library. I did not want to continue original discussion, cause I did not want to interfere with the review (I actually believe wave is a valuable tool that needed to be accepted). In following items I will try to justify my position that it (wave tool/library) needs to be treated as a tool not a library: I. It doesn't really fit into our library review model 1. Any review period wouldn't be enough for the majority of reviewer to get any (if any) decent look on implementation. Not only because it quite big, but because it require special knowledge 2. To be able to give any opinion on the design, one need essentially detail knowledge of C++ specification in regards to preprocessor. And I couldn't see how reviewer could see how design meet the requirements within review period. 3. Reviewers couldn't run test to check this tool do what it supposed to do. II. It has different target audience then boost libs I believe that in 99.99% of use cases it is going to be used as a tool, not as a library. One could probably need custom C++ preprocessor, but only in academic purposes, and definitely not in production. III. It doesn't really fit a maintenance model I don't see that any tester will ever run regression tests for the wave. And definitely not on regular basic as we do with rest of boost libs. IV. It doesn't really fit distribution model We distribute our libraries in a form of source code. It doesn't seems reasonable for wave. It should be distributed in a binary form. As I said majority of it's target audience will use it as a tool and shouldn't be punished if they use a compiler that couldn't handle spirit for example. On the other hand we are adding meg of source code that nobody (almost) will ever look into (other then spend time to compile a tool). Also documentation for this tool should be really tool-user directed - no need for the implementation to blur the view unless one is interested in it. I believe we need to introduce formal division on tools and libraries within boost. We already have couple useful tools that my have usage outside of boost (we need to document the first), I see several others that could be added. The review procedure for the tools should be different from the libraries. Essentially we need to review only the users guides and run already rebuilt executables. There may be something else I missing, we should discuss it. I believe there is a reason why language working group is separate from library working group in standardization committee. Let's keep clear separation of concepts here also. Regards, Gennadiy
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
Hi,
I would like to reiterate my concern about wave tool/library. I did not want to continue original discussion, cause I did not want to interfere with the review (I actually believe wave is a valuable tool that needed to be accepted). In following items I will try to justify my position that it (wave tool/library) needs to be treated as a tool not a library:
I. It doesn't really fit into our library review model
1. Any review period wouldn't be enough for the majority of reviewer to get any (if any) decent look on implementation. Not only because it quite big, but because it require special knowledge 2. To be able to give any opinion on the design, one need essentially detail knowledge of C++ specification in regards to preprocessor. And I couldn't see how reviewer could see how design meet the requirements within review period. 3. Reviewers couldn't run test to check this tool do what it supposed to do.
Why not?
II. It has different target audience then boost libs
I believe that in 99.99% of use cases it is going to be used as a tool, not as a library. One could probably need custom C++ preprocessor, but only in academic purposes, and definitely not in production.
III. It doesn't really fit a maintenance model
I don't see that any tester will ever run regression tests for the wave. And definitely not on regular basic as we do with rest of boost libs.
Why not?
IV. It doesn't really fit distribution model
We distribute our libraries in a form of source code.
We also distribute our tools that way. We have pre-built binaries of bjam for a few select platforms, but that's just a convenience. I don't believe bcp, regression, et. al are distributed as binaries.
It doesn't seems reasonable for wave. It should be distributed in a binary form. As I said majority of it's target audience will use it as a tool and shouldn't be punished if they use a compiler that couldn't handle spirit for example.
What kind of punishment do you envision?
On the other hand we are adding meg of source code that nobody (almost) will ever look into (other then spend time to compile a tool). Also documentation for this tool should be really tool-user directed - no need for the implementation to blur the view unless one is interested in it.
I believe we need to introduce formal division on tools and libraries within boost. We already have couple useful tools that my have usage outside of boost (we need to document the first), I see several others that could be added. The review procedure for the tools should be different from the libraries. Essentially we need to review only the users guides and run already rebuilt executables.
If tool portability matters (and it often does), it seems to me testing the build may be important.
There may be something else I missing, we should discuss it.
I believe there is a reason why language working group is separate from library working group in standardization committee.
How do those reasons apply to us?
Let's keep clear separation of concepts here also.
I'm not neccessarily opposed to what you're advocating, but so far you haven't made a clear case that it will have benefits, or that doing otherwise will have a cost. Could you boil the pros/cons down to a bullet list or something? -- Dave Abrahams Boost Consulting www.boost-consulting.com
3. Reviewers couldn't run test to check this tool do what it
supposed
to do.
Why not?
1. Because from what I understand one need quite expensive test harness for that. 2. It require quite a lot of time and resources.
II. It has different target audience then boost libs
I believe that in 99.99% of use cases it is going to be used as a tool, not as a library. One could probably need custom C++ preprocessor, but only in academic purposes, and definitely not in production.
III. It doesn't really fit a maintenance model
I don't see that any tester will ever run regression tests for the wave. And definitely not on regular basic as we do with rest of boost libs.
Why not?
See above
IV. It doesn't really fit distribution model
We distribute our libraries in a form of source code.
We also distribute our tools that way. We have pre-built binaries of bjam for a few select platforms, but that's just a convenience. I don't believe bcp, regression, et. al are distributed as binaries.
It doesn't seems reasonable for wave. It should be distributed in a binary form. As I said majority of it's target audience will use it as a tool and shouldn't be punished if they use a compiler that couldn't handle spirit for example.
What kind of punishment do you envision?
I want to use wave preprocessor instead of compiler supplied because it's buggy, nonconformant e.t.c. but couldn't do so because I couldn't compile one with my compiler for the same reasons.
I believe there is a reason why language working group is separate from library working group in standardization committee.
How do those reasons apply to us?
I thought it should be clear: imagine if all C++ issues both core language and STL development would be discussed in a single big group. They are separated because they represent different domains. Libraries and tools are also separate domains with different requirements for portability, clarity, flexibility. Tools for us more like black box - we don't need to know how they do their work. While with libraries we interested how they do, whatever they do. Libraries directed for the end user to compile with. Tools on the other hand are to be executed.
Let's keep clear separation of concepts here also.
I'm not necessarily opposed to what you're advocating, but so far you haven't made a clear case that it will have benefits, or that doing otherwise will have a cost. Could you boil the pros/cons down to a bullet list or something?
Ok. Let's see what are pros/cons in treating wave (and any other tool) as a separate notion: PROS No need to deliver source code or it could be separate package - in case of big tool in could be significant savings in delivery package size End user do not need to compile it End user could use it even if doesn't have a compiler that is able to compile one We don't need to spent time in /resolve issues with regression testing, which in many cases is either impossible and/or very time consuming Tool author do not need to spend time writing reference and any other documentation that covers internals Tool author do not really need to follow all boost guidelines to insure code quality - eventually this will speed up time before tool appear Review is simplified - actually tools reviews could be in separate queue and run concurrently with libs reviews CONS Users interested in using tool as a library will need to download an extra package Tool author may need to prepare two version of docs - one for end user and one for lib user Some extra initial work to introduce this notions separation from both organization and implementation stand point We kinda moving in nearby areas in software development space (libraries vs. tools that help write libraries). But this is OK IMO. I may've missed something Regards, Gennadiy
Gennadiy Rozental wrote:
snipped... I thought it should be clear: imagine if all C++ issues both core language and STL development would be discussed in a single big group. They are separated because they represent different domains. Libraries and tools are also separate domains with different requirements for portability, clarity, flexibility. Tools for us more like black box - we don't need to know how they do their work. While with libraries we interested how they do, whatever they do. Libraries directed for the end user to compile with. Tools on the other hand are to be executed.
Wave is not just a tool, if one defines a tool as just a program to run with some command line options, or a GUI in which one fills in some dialog and runs. While Wave has a command line, it also has a programming interface which allows one to examine the preprocessing tokens and even do some traces for macro expansion. Because it has a programming interface which allows a programmer to use it for his/her own purposes, it fulfills IMO the library concept as used in Boost, even though it also presents a tool command line concept. For this reason I do not think Wave will necessarily be treated like a black box by all programmers, so I do not find your argument to treat it differently than a Boost library compelling. To me, if it has a programming interface, it is a "library" in Boost terms, and Wave definitely has that.
Wave is not just a tool, if one defines a tool as just a program to run with some command line options, or a GUI in which one fills in some dialog and runs. While Wave has a command line, it also has a programming interface
I am not saying it could not be used as a mean for creating custom preprocessor. But I do see it used this way only for some arcane and/or academic purposes, which IMO will cover quite small portion of it's users. And I do not see why the rest of us should be faced with library that will never be tested, require comparatively advanced compilers and need to do actual compilation before it could be used, with very limited understanding from majority of the community how it's working. While instead we could have excellent tool that works with all compilers, delivered in a format desirable by majority of it's users without need for compilation and simple usage docs. I guess an ability to create a custom C++ preprocessors (when even to start using wave this way one needs to be an expect in C++ preprocessor standard) is not compelling enough for me to justify an inconvenience for the majority of the users. Gennadiy
Gennadiy Rozental wrote:
Wave is not just a tool, if one defines a tool as just a program to run with some command line options, or a GUI in which one fills in some dialog and runs. While Wave has a command line, it also has a programming interface
I am not saying it could not be used as a mean for creating custom preprocessor. But I do see it used this way only for some arcane and/or academic purposes, which IMO will cover quite small portion of it's users.
Agreed on that. But there are other libraries in Boost as well which 'suffer' from the same 'problem'.
And I do not see why the rest of us should be faced with library that will never be tested,
I don't know why you're so sure this library never will be tested. As I've said during the review I'm working on a test suite, which can be run as an integral part of the regression process. But please consider this to be not a simple task, so I'll need some additional time to fulfill my promise.
require comparatively advanced compilers and need to do actual compilation before it could be used
This is a real problem, and I'm aware of it. I assume you're interested in compiling Wave with VC6? I'm willing to work on that if there is only a real need in the community. Wave doesn't use any advanced C++ features which couldn't be replaced for older compilers. So I'm pretty confident that this could be done.
, with very limited understanding from majority of the community how it's working. While instead we could have excellent tool that works with all compilers, delivered in a format desirable by majority of it's users without need for compilation and simple usage docs.
I don't see how the tool could be 'excellent' if the library the tool relies on is not. And I think it shouldn't be a problem to provide precompiled binaries along with the boost releases on some major platforms. Perhaps this would help to remove your initial concern?
I guess an ability to create a custom C++ preprocessors (when even to start using wave this way one needs to be an expect in C++ preprocessor standard) is not compelling enough for me to justify an inconvenience for the majority of the users.
What inconvinience are you actually facing? Sorry, but I did get it yet. Regards Hartmut
I am not saying it could not be used as a mean for creating custom preprocessor. But I do see it used this way only for some arcane and/or academic purposes, which IMO will cover quite small portion of it's users.
Agreed on that. But there are other libraries in Boost as well which 'suffer' from the same 'problem'.
For example?
And I do not see why the rest of us should be faced with library that will never be tested,
I don't know why you're so sure this library never will be tested. As I've said during the review I'm working on a test suite, which can be run as an integral part of the regression process. But please consider this to be not a simple task, so I'll need some additional time to fulfill my promise.
Will it cover all the clauses from standard specification? How long will it run?
require comparatively advanced compilers and need to do actual compilation before it could be used
This is a real problem, and I'm aware of it. I assume you're interested in compiling Wave with VC6?
Actually I would be more interested in old sun and gcc compilers. But this is beyond the point.
I'm willing to work on that if there is only a real need in the community. Wave doesn't use any advanced C++ features which couldn't be replaced for older compilers. So I'm pretty confident that this could be done.
No. I think it would be a waste to invest your efforts to try to make it compile for old compilers. After all those users who interested in compiling custom preprocessor should be able to get a hold of latest gcc.
, with very limited understanding from majority of the community how it's working. While instead we could have excellent tool that works with all compilers, delivered in a format desirable by majority of it's users without need for compilation and simple usage docs.
I don't see how the tool could be 'excellent' if the library the tool relies on is not.
Oh! I know numerous example like that. I had an unfortunate need to modify some behavior in doxygen recently - and I really disliked the way it's written. But it doesn't make this tool less valuable. Note I am not saying anything about the wave library - I did not (and should not) look into it's internals.
And I think it shouldn't be a problem to provide precompiled binaries along with the boost releases on some major platforms. Perhaps this would help to remove your initial concern?
I believe we (boost) need a formal notion of a tool that is delivered as a binary plus source code for those platforms we did not provide binary for. BTW binary shouldn't be a part of main delivery packager - only docs should.
I guess an ability to create a custom C++ preprocessors (when even to start using wave this way one needs to be an expect in C++ preprocessor standard) is not compelling enough for me to justify an inconvenience for the majority of the users.
What inconvenience are you actually facing? Sorry, but I did get it yet.
Let's say I want an apple sauce. Instead you giving me an apples (they may be good ones or not so much, since for sauce it doesn't really matter and why waste good apples on sauce) and saying that if I have powerful enough mixer (or whatever it called) I could get a sauce in just a second. And the reason you are telling me is that there are some people out there who may've want slightly less sugar. I believe it's not good enough: give me my sauce - I do not want spend time making one, I do not have an appropriate mixer and I do not have a space to store all these apples.
Regards Hartmut
Regards, Gennadiy
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
What inconvenience are you actually facing? Sorry, but I did get it yet.
Let's say I want an apple sauce. Instead you giving me an apples (they may be good ones or not so much, since for sauce it doesn't really matter and why waste good apples on sauce) and saying that if I have powerful enough mixer (or whatever it called) I could get a sauce in just a second. And the reason you are telling me is that there are some people out there who may've want slightly less sugar. I believe it's not good enough: give me my sauce - I do not want spend time making one, I do not have an appropriate mixer and I do not have a space to store all these apples.
I understand what you're saying. On the other hand "install from source" has become a standard practice in the open-source world. The only thing that seems to make that argument less applicable than it would otherwise be is that this software requires a fairly conformant compiler. Right? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7jjz66s2.fsf@boost-consulting.com...
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
What inconvenience are you actually facing? Sorry, but I did get it yet.
Let's say I want an apple sauce. Instead you giving me an apples (they may be good ones or not so much, since for sauce it doesn't really matter and why waste good apples on sauce) and saying that if I have powerful enough mixer (or whatever it called) I could get a sauce in just a second. And the reason you are telling me is that there are some people out there who may've want slightly less sugar. I believe it's not good enough: give me my sauce - I do not want spend time making one, I do not have an appropriate mixer and I do not have a space to store all these apples.
I understand what you're saying. On the other hand "install from source" has become a standard practice in the open-source world. The only thing that seems to make that argument less applicable than it would otherwise be is that this software requires a fairly conformant compiler. Right?
Not only. 1. "install from source" practice is more *nix oriented. Cygwin for example doesn't require user to compile it's components 2. Wave at the moment does require conformant compiler while end ser may want to use it with different one 3. Boost is distributed as a set of libraries. The main point I am trying to make it we should separate tools into standalone packages and: a. Main delivery package includes only users docs plus location where prebuilt binaries are and where the source package is b. We prebuilt tools for some set of OSs c. Source package include reference docs and instruction how to build an executable from sources This practice could be applied to any tools including bjam and wave Gennadiy
On Tue, Mar 22, 2005 at 12:18:10PM -0500, Gennadiy Rozental wrote:
2. Wave at the moment does require conformant compiler while end ser may want to use it with different one
Why should you have to compile Wave with the non-conformant compiler in order to use wave with it? Download GCC, build Wave, delete GCC, then use Wave to replace your non-conformant compiler's preprocessor. This isn't ideal, but it's not impossible and allows Wave to be used on any platform that GCC runs on. What am I missing? Why should it be a requirement that Wave be compilable with all broken compilers that might want a better CPP ? jon -- "That invisible hand of Adam Smith's seems to offer an extended middle finger to an awful lot of people." - George Carlin
"Jonathan Wakely" <cow@compsoc.man.ac.uk> wrote in message news:20050322174452.GA96438@compsoc.man.ac.uk...
On Tue, Mar 22, 2005 at 12:18:10PM -0500, Gennadiy Rozental wrote:
2. Wave at the moment does require conformant compiler while end ser may want to use it with different one
Why should you have to compile Wave with the non-conformant compiler in order to use wave with it?
Download GCC, build Wave, delete GCC, then use Wave to replace your non-conformant compiler's preprocessor.
This isn't ideal, but it's not impossible and allows Wave to be used on any platform that GCC runs on.
What am I missing? Why should it be a requirement that Wave be compilable with all broken compilers that might want a better CPP ?
It shouldn't. And it was exactly my point. <side> Also I do not see why I need to compile it in a first place. If I follow the logic that all open source tools need to be delivered in a form of source code, then above procedure will include downloading gcc sources and building gcc. All this lead to some ... well inconvenience. </sidenote> Wave is in a different domain. It's primary user do not bother about portability, code clarity, design pattern. That's why we also need to treat it differently. Gennadiy
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7jjz66s2.fsf@boost-consulting.com...
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
What inconvenience are you actually facing? Sorry, but I did get it yet.
Let's say I want an apple sauce. Instead you giving me an apples (they may be good ones or not so much, since for sauce it doesn't really matter and why waste good apples on sauce) and saying that if I have powerful enough mixer (or whatever it called) I could get a sauce in just a second. And the reason you are telling me is that there are some people out there who may've want slightly less sugar. I believe it's not good enough: give me my sauce - I do not want spend time making one, I do not have an appropriate mixer and I do not have a space to store all these apples.
I understand what you're saying. On the other hand "install from source" has become a standard practice in the open-source world. The only thing that seems to make that argument less applicable than it would otherwise be is that this software requires a fairly conformant compiler. Right?
Not only.
1. "install from source" practice is more *nix oriented.
Irrelevant to whether that argument is less applicable to wave.
Cygwin for example doesn't require user to compile it's components
Cygwin is *nix. This is just the same as any other *nix system, where precompiled binary packages are produced by the maintainers of the OS. If I want some other arbitrary thing, like some special version of GCC, I install from source just as I would on any *nix system. I've done it many times. Yes, many projects supply precompiled binaries, but if I want something to work reliably in my environment I often find myself building it. In fact, that's the standard way to get a Python installation on *nix.
2. Wave at the moment does require conformant compiler while end ser may want to use it with different one
Yes, that's the one argument I was saying was applicable.
3. Boost is distributed as a set of libraries. The main point I am trying to make it we should separate tools into standalone packages and: a. Main delivery package includes only users docs plus location where prebuilt binaries are and where the source package is
you're suggesting that you get neither source nor tools with the "main Boost package?" That doesn't sound right.
b. We prebuilt tools for some set of OSs
Okay, well the wave tool isn't special in that regard; we have other tools we're not prebuilding.
c. Source package include reference docs and instruction how to build an executable from sources
Whoa; you intend to separate "users docs" from "reference docs?" That's a major change.
This practice could be applied to any tools including bjam and wave
And bcp, and... This sounds like a pretty ambitious plan for restructuring what we deliver. I do agree wholeheartedly that we need to reconsider the structure of what we deliver, but I don't neccessarily think this is the right plan. It doesn't seem to have precedent (at least not that I've seen), and I'd want to see a much more detailed rationale before buying into the details as you've described them. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
If I want some other arbitrary thing, like some special version of GCC, I install from source just as I would on any *nix system. I've done it many times.
Yes, many projects supply precompiled binaries, but if I want something to work reliably in my environment I often find myself building it. In fact, that's the standard way to get a Python installation on *nix.
I very much doubt that this is typical, especially in the windows world. I, for instance, always prefer binaries, if available, since I usually don't want to become an expert in a tool, and the standard configuration is good enough for me. Why not have both? Regards, Arkadiy
Arkadiy Vertleyb wrote:
"David Abrahams" <dave@boost-consulting.com> wrote
If I want some other arbitrary thing, like some special version of GCC, I install from source just as I would on any *nix system. I've done it many times.
Yes, many projects supply precompiled binaries, but if I want something to work reliably in my environment I often find myself building it. In fact, that's the standard way to get a Python installation on *nix.
I very much doubt that this is typical, especially in the windows world. I, for instance, always prefer binaries, if available, since I usually don't want to become an expert in a tool, and the standard configuration is good enough for me.
Why not have both?
Isn't that beside the point ? Whether and how to provide binary packages for boost or any of its components is a packaging issue, and unrelated to whether boost-the-project should host wave-the-library and wave-the-tool. Sometimes people seem to forget that the availability of software in source form is a feature, not an inconvenience. Regards, Stefan
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
If I want some other arbitrary thing, like some special version of GCC, I install from source just as I would on any *nix system. I've done it many times.
Yes, many projects supply precompiled binaries, but if I want something to work reliably in my environment I often find myself building it. In fact, that's the standard way to get a Python installation on *nix.
I very much doubt that this is typical, especially in the windows world.
I know; Windows is my primary platform.
I, for instance, always prefer binaries, if available, since I usually don't want to become an expert in a tool, and the standard configuration is good enough for me.
Why not have both?
No problem. I'm just saying that installation from source makes as much sense for wave as for any other open-source package, except possibly for its reliance on a reasonably conformant C++ compiler. -- Dave Abrahams Boost Consulting www.boost-consulting.com
This practice could be applied to any tools including bjam and wave
And bcp, and...
This sounds like a pretty ambitious plan for restructuring what we deliver. I do agree wholeheartedly that we need to reconsider the structure of what we deliver, but I don't neccessarily think this is the right plan. It doesn't seem to have precedent (at least not that I've seen), and I'd want to see a much more detailed rationale before buying into the details as you've described them.
Actually this discussion moved slightly beside the point. My original point was that wave should be treated as a tool (like bjam). If (once) we agree on that we could discuss in detail what should it means. bjam could in theory be used as library to implement custom build systems. bcp could in theory be used as library to implement different code split utilities. wave could be used to build custom c++ preprocessors. We could even have c++ compiler that could be used as a library to implement custom compilers for c++ with extensions. But I believe we need to treat them all as a tools - whatever that means we decide later. Gennadiy
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
This practice could be applied to any tools including bjam and wave
And bcp, and...
This sounds like a pretty ambitious plan for restructuring what we deliver. I do agree wholeheartedly that we need to reconsider the structure of what we deliver, but I don't neccessarily think this is the right plan. It doesn't seem to have precedent (at least not that I've seen), and I'd want to see a much more detailed rationale before buying into the details as you've described them.
Actually this discussion moved slightly beside the point. My original point was that wave should be treated as a tool (like bjam). If (once) we agree on that we could discuss in detail what should it means.
But that's backwards! I certainly can't agree that it should be treated like a tool without understanding its implications.
bjam could in theory be used as library to implement custom build systems.
Not really, its design is not appropriate for use as a library.
bcp could in theory be used as library to implement different code split utilities. wave could be used to build custom c++ preprocessors. We could even have c++ compiler that could be used as a library to implement custom compilers for c++ with extensions. But I believe we need to treat them all as a tools - whatever that means we decide later.
It's hard to see how you can hold a belief so strongly without even understanding what it means. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Actually this discussion moved slightly beside the point. My original point was that wave should be treated as a tool (like bjam). If (once) we agree on that we could discuss in detail what should it means.
But that's backwards! I certainly can't agree that it should be treated like a tool without understanding its implications.
No, it's not. I just propose to treat wave the same way we treat other tools in boost. Later on we could decide if we need to revise this treatment (for all tools). These are two independent decisions. Gennadiy
Gennadiy Rozental wrote:
Actually this discussion moved slightly beside the point. My original point was that wave should be treated as a tool (like bjam).
Still, besides your believes you haven't provided any valueable argument for this. There are at least 3 projects going on I know of where Wave is used as a library and is incorporated into a tool on its own. I'm sure, with the inclusion of Wave into Boost this trend will increase.
If (once) we agree on that we could discuss in detail what should it means.
We have not agreed yet.
bjam could in theory be used as library to implement custom build systems. bcp could in theory be used as library to implement different code split utilities. wave could be used to build custom c++ preprocessors. We could even have c++ compiler that could be used as a library to implement custom compilers for c++ with extensions. But I believe we need to treat them all as a tools - whatever that means we decide later.
Here I've lost you again, *sigh*. Regards Hartmut
Gennadiy Rozental wrote:
Agreed on that. But there are other libraries in Boost as well which 'suffer' from the same 'problem'.
For example?
Boost.Python isn't so widely used and a niche library aimed to solve a very specific problem, for instance.
I don't know why you're so sure this library never will be tested. As I've said during the review I'm working on a test suite, which can be run as an integral part of the regression process. But please consider this to be not a simple task, so I'll need some additional time to fulfill my promise.
Will it cover all the clauses from standard specification?
Why not?
How long will it run?
Can't estimate?
This is a real problem, and I'm aware of it. I assume you're interested in compiling Wave with VC6?
Actually I would be more interested in old sun and gcc compilers. But this is beyond the point.
I'm willing to work on that if there is only a real need in the community. Wave doesn't use any advanced C++ features which couldn't be replaced for older compilers. So I'm pretty confident that this could be done.
No. I think it would be a waste to invest your efforts to try to make it compile for old compilers. After all those users who interested in compiling custom preprocessor should be able to get a hold of latest gcc.
That was my initial thinking when I decided to write Wave ignoring older compilers, so I don't understand your initial concern anymore.
I don't see how the tool could be 'excellent' if the library the tool relies on is not.
Oh! I know numerous example like that. I had an unfortunate need to modify some behavior in doxygen recently - and I really disliked the way it's written. But it doesn't make this tool less valuable. Note I am not saying anything about the wave library - I did not (and should not) look into it's internals.
Again, I don't understand your initial concern anymore.
And I think it shouldn't be a problem to provide precompiled binaries along with the boost releases on some major platforms. Perhaps this would help to remove your initial concern?
I believe we (boost) need a formal notion of a tool that is delivered as a binary plus source code for those platforms we did not provide binary for. BTW binary shouldn't be a part of main delivery packager - only docs should.
That's out of question.
What inconvenience are you actually facing? Sorry, but I did get it yet.
Let's say I want an apple sauce. Instead you giving me an apples (they may be good ones or not so much, since for sauce it doesn't really matter and why waste good apples on sauce) and saying that if I have powerful enough mixer (or whatever it called) I could get a sauce in just a second. And the reason you are telling me is that there are some people out there who may've want slightly less sugar. I believe it's not good enough: give me my sauce - I do not want spend time making one, I do not have an appropriate mixer and I do not have a space to store all these apples.
Sorry, now I've lost you completely. I'm not able to follow your metaphers here. What are the apples? - Boost? And what's the sugar? - Wave? Regards Hartmut
Let's say I want an apple sauce. Instead you giving me an apples (they may be good ones or not so much, since for sauce it doesn't really matter and why waste good apples on sauce) and saying that if I have powerful enough mixer (or whatever it called) I could get a sauce in just a second. And the reason you are telling me is that there are some people out there who may've want slightly less sugar. I believe it's not good enough: give me my sauce - I do not want spend time making one, I do not have an appropriate mixer and I do not have a space to store all these apples.
Sorry, now I've lost you completely. I'm not able to follow your metaphers here. What are the apples? - Boost? And what's the sugar? - Wave?
Apples - is your source (files) Apple sause - is you product - Wave C++ preprocessor Sugar - is a minor configuration difference Mixer - compiler
Regards Hartmut
Gennadiy
Hartmut Kaiser wrote:
Gennadiy Rozental wrote:
And I do not see why the rest of us should be faced with library that will never be tested,
I don't know why you're so sure this library never will be tested. As I've said during the review I'm working on a test suite, which can be run as an integral part of the regression process. But please consider this to be not a simple task, so I'll need some additional time to fulfill my promise.
I'm presently working on integrating wave as a Cpp backend for synopsis. In particular, I'm trying to parse (Cpp and C++) boost itself, which appears to be a good acid test. One of the difficulties testing a tool/library such as wave on a large scale seems to me to be the system/platform specific nature of such a task. As soon as you leave the scale of unit tests, you'll end up with system-dependent headers that require knowledge about system compilers. In synopsis I use some python code that scans the system for available compilers and tries to extract predefined macros and include search paths. Would such a facility help as a means for more people to test wave ? What I have in mind is a python wrapper script that runs the 'wave' tool, forwarding user-defined arguments, but which essentially emulates a system compiler in that it predefines macros and include paths according to its findings. Regards, Stefan
On 03/22/2005 11:04 AM, Stefan Seefeld wrote: [snip]
One of the difficulties testing a tool/library such as wave on a large scale seems to me to be the system/platform specific nature of such a task. As soon as you leave the scale of unit tests, you'll end up with system-dependent headers that require knowledge about system compilers.
I thought that boost build solved that problem. Can't you use that?
Larry Evans wrote:
On 03/22/2005 11:04 AM, Stefan Seefeld wrote: [snip]
One of the difficulties testing a tool/library such as wave on a large scale seems to me to be the system/platform specific nature of such a task. As soon as you leave the scale of unit tests, you'll end up with system-dependent headers that require knowledge about system compilers.
I thought that boost build solved that problem. Can't you use that?
Sorry if I wasn't clear. I'm not talking about the knowledge required to compile wave, but the knowledge required to use wave-the-tool on non-trivial C/C++ input. Whenever wave parses something as simple as "#include <string>" it needs to have a *lot* of knowledge about system-dependent details, as system headers usually contain a lot of instructions that assume a particular compiler. In fact, often system headers are shipped *with* a specific compiler to make that work out. Regards, Stefan
On 03/22/2005 11:49 AM, Stefan Seefeld wrote:
Sorry if I wasn't clear. I'm not talking about the knowledge required to compile wave, but the knowledge required to use wave-the-tool on non-trivial C/C++ input. Whenever wave parses something as simple as "#include <string>" it needs to have a *lot* of knowledge about system-dependent details, as system headers usually contain a lot of
Ah yes, I remember having that problem during my attempt at testing wave for the review. Now that I understand, I think the tool you mentioned earlier would be very useful. The quick-and-dirty method I used first compiled the file with -E and then I manually picked out the system include files from the compiler's -E output and used that to create a Makefile macro. Not the best way ;)
Stefan Seefeld wrote:
Hartmut Kaiser wrote:
Gennadiy Rozental wrote:
And I do not see why the rest of us should be faced with library that will never be tested,
I don't know why you're so sure this library never will be tested. As I've said during the review I'm working on a test suite, which can be run as an integral part of the regression process. But please consider this to be not a simple task, so I'll need some additional time to fulfill my promise.
I'm presently working on integrating wave as a Cpp backend for synopsis. In particular, I'm trying to parse (Cpp and C++) boost itself, which appears to be a good acid test. One of the difficulties testing a tool/library such as wave on a large scale seems to me to be the system/platform specific nature of such a task. As soon as you leave the scale of unit tests, you'll end up with system-dependent headers that require knowledge about system compilers. In synopsis I use some python code that scans the system for available compilers and tries to extract predefined macros and include search paths.
Would such a facility help as a means for more people to test wave ? What I have in mind is a python wrapper script that runs the 'wave' tool, forwarding user-defined arguments, but which essentially emulates a system compiler in that it predefines macros and include paths according to its findings.
Most compilers will publish a list of predefined macros. However some predefined macros depend on the command line options that one passes to the compilers when compiling source. So such a tool as yours must take into account a set of options being passed to it that would change the predefined macros generated. Also, of course, it is possible that macros can be defined for a compiler as a command-line option itself. Similarly the final include path must also take into account any command line option, most popularly "-isome_path;some_path_etc", which is passed to the compiler when it is invoked. What all this means is that, for any given compiler, a tool such as yours ideally needs to accept the same set of command-line options as the particular compiler accepts, and know how to set any macros, as well as a final composite include path, from those options.
Edward Diener wrote:
What all this means is that, for any given compiler, a tool such as yours ideally needs to accept the same set of command-line options as the particular compiler accepts, and know how to set any macros, as well as a final composite include path, from those options.
Indeed, that is basically how it works. Up to this point I have only used it to emulate various versions of gcc and MSVC, but it shouldn't be hard to extend to others. The hard part is really to know how to detect a compiler and how to determine the predefined macros and paths. The passing through of unknown options is simple, as the wrapper doesn't need to interpret anything. It's just a proxy after all. Regards, Stefan
participants (8)
-
Arkadiy Vertleyb -
David Abrahams -
Edward Diener -
Gennadiy Rozental -
Hartmut Kaiser -
Jonathan Wakely -
Larry Evans -
Stefan Seefeld