Hi Hartmut, I wanted to try out the examples. I encountered some problems: + Read the quikstart to get me started immediately. "Do not instantiate the main, preprocessing iterators yourself." --> not enough context here. "main" is undefined at this point. + when using bjam V2, VC7.1 fails with a buffer overrun (compiler problem). No problem with bjam V1. I wanted to try the samples but they don't have a V1 Jamfile, only V2. So I had to switch to using g++ instead. So far so good. + Now, I'm able to build the samples using bjam V2. A little hickup: bjam complains: error: Unable to find file or target named error: '/boost/program_options//boost_program_options' error: referred from project at error: 'cpp_tokens/build' Looking at program_options, it seems that the library name is program_options (without the boost_ prefix). + Got this fixed and. Now got into a link error: gcc.link ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\ release\inspect.exe ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\release\ cpp_main.o(.text+0x50):cpp_ ain.cpp: multiple definition of `_main' ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\ release\inspect.o(.text+0x7eb0):ins ect.cpp: first defined here Any clues? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
I wanted to try out the examples. I encountered some problems:
+ Read the quikstart to get me started immediately. "Do not instantiate the main, preprocessing iterators yourself." --> not enough context here. "main" is undefined at this point.
That should read: "Do not instantiate the main preprocessing iterators yourself." I meant, that the iterators used to get back the preprocessed tokens should not be instantiated directly.
+ when using bjam V2, VC7.1 fails with a buffer overrun (compiler problem). No problem with bjam V1. I wanted to try the samples but they don't have a V1 Jamfile, only V2. So I had to switch to using g++ instead. So far so good.
Sure they have, haven't they? I'm pretty sure that I've added V1 Jamfile's. But thanks for reporting the V2 problems. Please add the line : <toolset>vc-7_1:<rtti>off # workaround for compiler bug to the V2 Jamfile's, without that VC7.1 simply fails - please look at the V2 Jamfile of the library itself for a sample ($BOOST_ROOT/libs/wave/build/Jamfile.v2).
+ Now, I'm able to build the samples using bjam V2. A little hickup: bjam complains: error: Unable to find file or target named error: '/boost/program_options//boost_program_options' error: referred from project at error: 'cpp_tokens/build' Looking at program_options, it seems that the library name is program_options (without the boost_ prefix).
This was reported already by Larry Evans, please change this line to: $(BOOST_ROOT)/boost/program_options//boost_program_options Yeah seems, the Jamfile.v2 files in the archive are completely broken, but that's because I'm mainly working with V1 files, so this sneaked in unnoticed...
+ Got this fixed and. Now got into a link error: gcc.link ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\ release\inspect.exe ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\release\ cpp_main.o(.text+0x50):cpp_ ain.cpp: multiple definition of `_main' ..\..\..\bin.v2\tools\inspect\build\gcc-3.2\ release\inspect.o(.text+0x7eb0):ins ect.cpp: first defined here
This is a linker error regarding the Boost inspect tool!? I have no clue what to do about this. HTH Regards Hartmut
Hartmut Kaiser wrote:
Joel de Guzman wrote:
+ when using bjam V2, VC7.1 fails with a buffer overrun (compiler problem). No problem with bjam V1. I wanted to try the samples but they don't have a V1 Jamfile, only V2. So I had to switch to using g++ instead. So far so good.
Sure they have, haven't they? I'm pretty sure that I've added V1 Jamfile's. But thanks for reporting the V2 problems. Please add the line
: <toolset>vc-7_1:<rtti>off # workaround for compiler bug
to the V2 Jamfile's, without that VC7.1 simply fails - please look at the V2 Jamfile of the library itself for a sample ($BOOST_ROOT/libs/wave/build/Jamfile.v2).
Hi Hartmut, VC7.1 still bombs with "buffer overrun". Here's the bjam output: C:\dev\boost\libs\wave\build>bjam --v2 ...found 108 targets... ...updating 5 targets... msvc.compile.c++ ..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiate_cpp_gram mar.obj instantiate_cpp_grammar.cpp call "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.ba t" > nul cl /Zm800 -nologo -TP -DBOOST_ALL_NO_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd -I"C :\dev\boost" -c -Fo"..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiate_cpp_ grammar.obj" "..\src\instantiate_cpp_grammar.cpp" ...failed msvc.compile.c++ ..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiat e_cpp_grammar.obj... Did I do something wrong? -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
VC7.1 still bombs with "buffer overrun". Here's the bjam output:
C:\dev\boost\libs\wave\build>bjam --v2 ...found 108 targets... ...updating 5 targets... msvc.compile.c++ ..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiate_cpp_gram mar.obj instantiate_cpp_grammar.cpp
call "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.ba t" > nul cl /Zm800 -nologo -TP -DBOOST_ALL_NO_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd -I"C :\dev\boost" -c -Fo"..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiate_cpp_ grammar.obj" "..\src\instantiate_cpp_grammar.cpp"
There is still the /GR option (enable rtti) on the command line. The '<toolset>vc-7_1:<rtti>off' option should switch this off (at least it does for the library itself ?-).
...failed msvc.compile.c++ ..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiat e_cpp_grammar.obj...
Did I do something wrong?
Could you double check please, that you've added the ': <toolset>vc-7_1:<rtti>off' to the Jamfile.v2? For instance the Jamfile for the quick_start sample should look like: exe quick_start : ../quick_start.cpp ../../../build//boost_wave : <toolset>vc-7_1:<rtti>off # workaround for compiler bug ; Otherwise I'm out of clues :-( Regards Hartmut
Hartmut Kaiser wrote:
Joel de Guzman wrote:
VC7.1 still bombs with "buffer overrun". Here's the bjam output:
C:\dev\boost\libs\wave\build>bjam --v2 ...found 108 targets... ...updating 5 targets... msvc.compile.c++ ..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiate_cpp_gram mar.obj instantiate_cpp_grammar.cpp
call "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.ba t" > nul cl /Zm800 -nologo -TP -DBOOST_ALL_NO_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd -I"C :\dev\boost" -c -Fo"..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiate_cpp_ grammar.obj" "..\src\instantiate_cpp_grammar.cpp"
There is still the /GR option (enable rtti) on the command line. The '<toolset>vc-7_1:<rtti>off' option should switch this off (at least it does for the library itself ?-).
...failed msvc.compile.c++ ..\..\..\bin.v2\libs\wave\build\msvc\debug\instantiat e_cpp_grammar.obj...
Did I do something wrong?
Could you double check please, that you've added the ': <toolset>vc-7_1:<rtti>off' to the Jamfile.v2? For instance the Jamfile for the quick_start sample should look like:
exe quick_start : ../quick_start.cpp ../../../build//boost_wave : <toolset>vc-7_1:<rtti>off # workaround for compiler bug ;
Otherwise I'm out of clues :-(
No, it is the library I am trying to build. It's always there. libs/wave/build/Jamfile.v2 has it: lib boost_wave : $(SOURCES).cpp /boost/filesystem//boost_filesystem : <toolset>vc-7_1:<rtti>off # workaround for compiler bug # Not supported by V2 # <no-warn>cpp.re.cpp ; I have no clue why it's still bombing. Anyway, I switched to bjam V1 and everything's fine. You might want to confirm this though. If it's any help, I'm testing Wave against Boost 1.32.0, not the current HEAD. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
exe quick_start : ../quick_start.cpp ../../../build//boost_wave : <toolset>vc-7_1:<rtti>off # workaround for compiler bug ;
Otherwise I'm out of clues :-(
No, it is the library I am trying to build. It's always there. libs/wave/build/Jamfile.v2 has it:
lib boost_wave : $(SOURCES).cpp /boost/filesystem//boost_filesystem : <toolset>vc-7_1:<rtti>off # workaround for compiler bug # Not supported by V2 # <no-warn>cpp.re.cpp ;
I have no clue why it's still bombing. Anyway, I switched to bjam V1 and everything's fine. You might want to confirm this though. If it's any help, I'm testing Wave against Boost 1.32.0, not the current HEAD.
The right syntax is <toolset>vc-7.1:<rtti>off not <toolset>vc-7_1:<rtti>off The change from dot to underscore happened at the last moment during 1.32 preparation because in V1, version names are encoded in toolset filenames, and ISO filesystem does not allow too many dots. In V2, we're still using dot. Also, for the above to work, you need to configure msvc with: using msvc : 7.1 ; not with just using msvc ; Otherwise, V2 won't know what version you're using. HTH, Volodya
Vladimir Prus wrote:
I have no clue why it's still bombing. Anyway, I switched to bjam V1 and everything's fine. You might want to confirm this though. If it's any help, I'm testing Wave against Boost 1.32.0, not the current HEAD.
The right syntax is
<toolset>vc-7.1:<rtti>off
not
<toolset>vc-7_1:<rtti>off
The change from dot to underscore happened at the last moment during 1.32 preparation because in V1, version names are encoded in toolset filenames, and ISO filesystem does not allow too many dots. In V2, we're still using dot.
Also, for the above to work, you need to configure msvc with:
using msvc : 7.1 ;
not with just
using msvc ;
Otherwise, V2 won't know what version you're using.
Thanks for the info! Regards Hartmut
Hartmut Kaiser wrote:
Vladimir Prus wrote:
The right syntax is
<toolset>vc-7.1:<rtti>off
not
<toolset>vc-7_1:<rtti>off
Actually, it should be: <toolset>msvc-7.1:<rtti>off since the VC++ toolset is called msvc in V2 and vc in V1. Also, the line <runtime-link>static should be: <link-runtime>static Regards, Reece
Reece Dunn wrote:
Actually, it should be:
<toolset>msvc-7.1:<rtti>off
since the VC++ toolset is called msvc in V2 and vc in V1.
Also, the line
<runtime-link>static
should be:
<link-runtime>static
Thanks for the correction. I hope to get my hands onto this soon, so I'll try it out asap. Regards Hartmut
Hartmut Kaiser wrote:
Thanks for the correction. I hope to get my hands onto this soon, so I'll try it out asap.
No problem. I also encountered problems with the program_option and filesystem (in both the tools and lib wave build) locations as already noted. Once these had been fixed, BBv2 complains about libs/wave/build not being able to locate libboost_wave-....lib. The problem here is to do with auto-linking. Thus, BOOST_WAVE_SOURCE is not being defined. This fixed, I got an error about tools/wave/build not being able to locate boost_wave.lib which was fixed by using link=static on the build command line. I now have a wave.exe executable :). NOTE: it might be useful to define an install command: install bin : wave ; to make the wave.exe file easier to find (instead of having to navigate multiple directory levels)! That done, I have successfully build wave on: * gcc-3.3 * msvc-7.1 * msvc-8.0 - albeit with a lot of deprecated warnings relating to sprintf, etc And get errors when compiling for: * msvc-7.0 - when building flex_string.hpp: 'std::reverse_iterator' - too many template arguments. Note that this can be fixed by using boost::reverse_iterator (which saves the reverse_iterator detection logic): #include <boost/iterator/reverse_iterator.hpp> // ... typedef boost::reverse_iterator< iterator > reverse_iterator; typedef boost::reverse_iterator< const_iterator > const_reverse_iterator; Note that I haven't tried building with this fix, although it should work fine. (It may need the <rtti>off fix for 7.1, though). Note that I have not tested on msvc-6.5 because it is unlikely that wave will compile on it. * cw-9.2 - there are a host of errors when building wave using Metrowerks CodeWarrior. These relate to: * undefined identifier 'time_t' (src/cpplexer/re2clex/cpp.re.cpp) * undefined identifiers memcpy, free, etc. * const size_t s = e - b; (boost/wave/util/flex_string.hpp) implicit 'int' is no longer supported in C++ I think that these relate to missing #include and using directives. E.g. using std::size_t; I will look into these errors. Regards, Reece
Reece Dunn wrote:
I also encountered problems with the program_option and filesystem (in both the tools and lib wave build) locations as already noted.
[snip] Thanks for your problem report. Do you mind to submit a patch of what you've been doing?
That done, I have successfully build wave on:
* gcc-3.3 * msvc-7.1 * msvc-8.0 - albeit with a lot of deprecated warnings relating to sprintf, etc
And get errors when compiling for:
* msvc-7.0 - when building flex_string.hpp: 'std::reverse_iterator' - too many template arguments. Note that this can be fixed by using boost::reverse_iterator (which saves the reverse_iterator detection logic):
Yeah, I know. Wave was never written to be compatible with 'older' compilers, which may be an issue in the future, but if there is real interest I'd try to fix it (which should be possible w/o much effort).
#include <boost/iterator/reverse_iterator.hpp>
// ...
typedef boost::reverse_iterator< iterator > reverse_iterator; typedef boost::reverse_iterator< const_iterator > const_reverse_iterator;
Note that I haven't tried building with this fix, although it should work fine. (It may need the <rtti>off fix for 7.1, though).
Note that I have not tested on msvc-6.5 because it is unlikely that wave will compile on it.
Same as above.
* cw-9.2 - there are a host of errors when building wave using Metrowerks CodeWarrior. These relate to: * undefined identifier 'time_t' (src/cpplexer/re2clex/cpp.re.cpp) * undefined identifiers memcpy, free, etc. * const size_t s = e - b; (boost/wave/util/flex_string.hpp) implicit 'int' is no longer supported in C++ I think that these relate to missing #include and using directives. E.g. using std::size_t;
I will look into these errors.
I don't have CW at my hands here, so any help is very appreciated! Regards Hartmut
Hartmut Kaiser wrote:
Joel de Guzman wrote:
+ when using bjam V2, VC7.1 fails with a buffer overrun (compiler problem). No problem with bjam V1. I wanted to try the samples but they don't have a V1 Jamfile, only V2. So I had to switch to using g++ instead. So far so good.
Sure they have, haven't they? I'm pretty sure that I've added V1 Jamfile's.
Ah yes, there are V1 files in each of the build directories. I was expecting a V1 file in the samples directory since there's a V2 file there (but not a V1). Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Hi Y'all, Here's my review of Wave: * What is your evaluation of the design? I think this is the most flexible pre-processor I know. It's a c++ library, so I expected full extensibility. Hartmut was very thorough in his design with more than enough links and hooks through policies and callbacks to do almost anything imaginable. The structure is highly modular. * What is your evaluation of the implementation? The implementation is very good. Hartmut has been a very avid Spirit developer and I've known him to be an excelent coder. I took a peek at the code, sure enough, he's a Spirit expert who can churn out really cool Spirit parsers. * What is your evaluation of the documentation? I think the documentation is fairly sufficient. There is still room for improvement though. * What is your evaluation of the potential usefulness of the library? Wave started out as a demo application for Spirit. I teased Hartmut into it. He accepted. This came as a challenge from Andrei Alexandrescu: http://lists.boost.org/MailArchives/boost/msg21052.php There's a real need for such a library and tool. I don't know how many times I wished for such a thing. Surely, we need tools to make tools to make tools. Wave is such a tool. It might be arguable if Wave should be considered a tool only (like Lex/Yacc) or a library. But Spirit has shown that developers can benifit a lot from making a tool a library. Parsing c++ is a difficult task, but we've got to start somewhere. I think Wave is an excelent start. Next stop should be a full C++ parser, also tweakable and accessible at the library level. * Did you try to use the library? With what compiler? Yes. VC7.1 and g++. Did you have any problems? Some minor problems relating to bjam. Not a showstopper. * How much effort did you put into your evaluation? I've been keenly watching Wave evolve from its inception. I spent a couple of hours for this review. A glance? A quick reading? In-depth study? I read the docs in full, studied the code in detail and tried all the examples. * Are you knowledgeable about the problem domain? I am not a PP expert. No, I am not an expert in the problem domain. I am an expert in the solution domain though (i.e. Spirit :-). And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Yes. I think Wave should be accepted. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (4)
-
Hartmut Kaiser -
Joel de Guzman -
Reece Dunn -
Vladimir Prus