Re: [Spirit-general] Re: Bug in phoenix/casts.hpp

[Dan N. <dn...@sc...>]

Noah Stein wrote:
>>-----Original Message-----
>>From: spi...@li...
>>[mailto:spi...@li...]On Behalf Of Dan
>>Nuffer
> 
> 
>>IMHO, the way to go is to write it with preprocessor, then preprocess
>>it, and distribute the preprocessed version, so it's possible to examine
>>the code and also step into it and debug.  Grated this is a little extra
>>work for the author, but it sure makes life easier for those who dig
>>into the code.
> 
> 
> IMHO, I am against that idea.  I don't like distributing source code that
> isn't really source code.  Spirit becomes a library that needs to be built
> even though it's all header files.
>

I don't understand this.  If we distribute the non-pp version in 
addition to the pp version, the user shouldn't have to build anything.


> The preprocessor definitely obscures the code.  I don't like that at all.
> It can make debugging a nightmare.  I hate that.  I think if the
> preprocessor library is to be used, the best course of action is to
> distribute the bpp-ized source.
> 
> If people want to see or use non-pp versions, it's almost guaranteed that
> their compilers can spit out post-preprocessed files.  I'd rather see a
> handy batch file include to do that than to put generated files into a
> distribution.
> 
> Every time I've dealt with non-source files in cvs or distributions, I've
> had a headache.  That might just be me, though.  My $0.02.
> 

What sorts of problems?

I think it can be mostly transparent if set up correctly.  For instance, 
in OpenWBEM, there are some flex & bison parsers.  One is mofparser.yy 
for illustration.  The Makefile automatically rebuilds mofparser.cc (and 
mofparser.o, etc.) if mofparser.yy changes.  When I run 'make dist' 
mofparser.cc gets bundled up in addition to mofparser.yy.  When a user 
downloads the source, they don't have to have bison installed in order 
to compile things, since mofparser.cc is distributed.  OpenWBEM's been 
around for nearly 2 years, and I've never had any problems because of 
the generated files.

I think Spirit can have a similar scenario.  Have a header called 
foo_using_pp.hpp
Then have a jam (& make) rule that will automatically generate foo.hpp 
whenever foo_using_pp.hpp changes.

All the code will actually include foo.hpp, so users can pinpoint errors 
and debug it.
We can distribute both foo.hpp and foo_using_pp.hpp.

It's good for the user: they can debug and maybe actually find compile 
errors.

It's also nice for the developer, the build system automatically takes 
care of generating foo.hpp & they can write code with (hopefully) less 
bugs using PP.

--Dan