Reece Dunn wrote:
The example above was an attempt to show how to override the preset default.qbk by providing one in one of the earlier search paths and how you might go about importing the default one (because [import default.qbk] would be recursive otherwise). The underlying idea was to show that it is possible to just have the one auto-included file (default.qbk) and that you can provide your user.qbk functionality by providing a custom default.qbk in a search path you specified in the command line or where the top-level qbk file is located.
In C/C++, an analogous thing would be providing your own <utility> header and overriding the one in your preferred standard library implementation and then including the utility header from that standard library implementation. (I am not saying that this is good practice, just that it is possible. However, on that note, if the TR1 extensions extend <functional> for example, this might be a valid technique to add the TR1 behaviours.)
Ahh, my bad... I didn't notice the "-- default.qbk" in your example, so I thought it was depicting a project's main qbk manually including "default.qbk". Time to get my eyes checked...
Someone's global "user.qbk" file might look like: ...
You could do a similar thing using my mechanism.
Yes, now that I see the context of your prior post, it seems the only thing I was actually adding was the idea of having a "user.qbk" in addition to "default.qbk". That would have been easier if I hadn't gotten distracted explaining why the end user shouldn't have to explicitly ask for "default.qbk", when you were already were well beyond understanding that... DOH!
In general, I think we should try and minimize the explicit use of [include ...] in "end user" project qbks importing files outside of the local directory. I agree with having a search path with a common central location, but it might be better for the long term clarity and maintainability of QuickBook based docs if such lookups are rarely necessary. We can do all kinds of cool and complicated things within the autoloaded "default.qbk" and "user.qbk", because the author who just wants to document part of his library doesn't have to know how that works, keeping the actual qbk(s) for their project as clean and simple as possible.
I agree. This is one reason for having the search paths on the command line. The situation where this becomes an issue is where you have the same file in path a and path b, the program selects the file from path a but you then (in the path a version) want to include the file from path b. In this instance, you *need* to be explicit in order to prevent recursion. Allowing the use of defs simplifies the process, especially if you move path b to a new location.
Yep, yep, yep...
... A more useful thing would be:
[def projectdir mydocs]
[include $(projectdir)/introduction.qbk] [include $(projectdir)/tutorial.qbk] [include $(projectdir)/references.qbk]
Indeed :)
This was a braindead moment on my part! Ignore the colour specification element of my suggestion. Of course CSS is definitely the way to do specify the styling.
Nah, you were on too much of a roll to be braindead. Momentarily distracted perhaps, but methinks your brain is plenty healthy... :)
:)
So, you know, now that I've had a taste, that shoe leather isn't so bad with a little salt ;)
- james
-- __________________________________________________________ James Fowler, Open Sea Consulting http://www.OpenSeaConsulting.com, Marietta, Georgia, USA Do C++ Right. http://www.OpenCpp.org, opening soon!
------------------------------------------------------- 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
