Joel de Guzman <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Joel de Guzman <[EMAIL PROTECTED]> writes: >> Hmm. I'm not sure I like having to label each snippet I might want >> to >> process with a collector. > > Do you have a certain suggestion in mind?
Did you look at Litre? There's only one collector, and snippets just collect there automatically. Maybe you should collect everything in the last collector used until instructed otherwise. >>>If the collector identifier is in quotes, the collector is >>>assumed to be a file. Example: >>> >>> [collect "test.cpp"] >>> >>>A file collector will collect all successive code snippets into >>> the specified file. >> >> When we have a way of labelling examples in quickbook, it would be >> nice if there were an automated way to turn the example label into a >> filename, e.g. chapter5/example13.cpp > > ? Won't [copy "chapter5/example13.cpp" label] handle that? > Ok, you say it should be: > > [copy label to "chapter5/example13.cpp"] I am presuming the numbering will be auto-generated by BoostBook, so we will want something to automatically generate the filename from that number. >>>All open files are closed at the end of quickbook processing. >> And then what? >> In C++ Template Metaprogramming I have examples that I want to >> compile, preprocess, build and run, or fail compilation. So far I >> don't see any connection to backend processing here. In Litre writing >> directives in Python means that I can embed semantics about the >> treatment of these snippets, and can extend the way they are >> handled. > > Here's my line of thinking, tell me what you think: > > Separation of concerns... > > I think that compiling, preprocessing, building and running, etc, > should not be the job for QuickBook. That's fine. In Litre there is also separation of concerns. There's the Litre framework and a C++-specific translator subclass that knows about this kind of processing. > Instead, this should be a > job of the build tool, in this case, BJam. I could, for example > have a "collector" that generates a Jamfile that can be > invoked automatically after the QuickBook session, perhaps > triggered by the same Jamfile that invoked the QuickBook session. > I figured that this would amount to the same thing. No? Sure, but then you need programmable collectors. Programming a collector to do this amounts to the same thing as writing a C++-specific translator for Litre. We don't want to rebuild quickbook each time you need a new collector behavior, so I think binding to an interpreted language (Python, please) is almost mandatory. You could do it with plug-in dynamic libraries, I suppose, but this is a job I just see no good reason to do in C++. >>>1) Copy src into destination. dest will have the same contents as src. >>> [copy dest src] >> Why not [copy src dest]? (from,to) is most natural for most of us, >> IMO. > > Sure. Agreed: > > [copy src to dest] :-) Now that's unambiguous! >> I don't see any facilities for results processing here. Also Litre > > See above. > >> has a lot of less-important features you haven't addressed here; not >> sure if you're intentionally leaving those out for now or it's an >> oversight. > > Oh, sure. Those are icings in the cake. As soon as the meat of the > facility is ironed out, it would be fun to have all these bells > and whistles :-) > > Thanks for your input! No problem. Thanks for pursuing this! -- Dave Abrahams Boost Consulting www.boost-consulting.com ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-docs mailing list [email protected] Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
