Vladimir Prus wrote:
error: Unable to find file or target named error: 'object(file-target)@427' error: referred from project at error: '/home/ghost/Work/Boost/boost/tools/quickbook'
As I've said, that message is a result of a bug in quickbook.jam. What are you trying to do here? Find and fix that bug? In order to conveniently do that, you must be familiar with Boost.Build internals.
Usually, this error is emitted when you mention non-existent file or target in the sources, and never caused confusion to any user. In
it's emitted due to quickbook.jam bug, and I don't think there's much
[snip] this case, point
to try making the message more helpful in case of internal bugs, given that to fix such bug you'd need to know a bit of Boost.Build anyway.
I took an initial look at it and the offending line in quickbook.jam appears to be lines 190-191, which look like this: quickbook-binary-dependencies = [ $(quickbook-main-target).generate $(property-set) ] ; quickbook-main-target is supposed to represent the main target in quickbooks own Jamfile and property-set is an argument for the run rule of the quickbook generator. I don't know how to fix it, yet. Is the problem here that I'm fiddling with the dependencies before they are built? Any ideas on how to circumvent that? I'll try to give it a longer look later... [snip]
Why is the deep wizardry in quickbook.jam necessary? Or is it? What it's trying to do is quite simple: "I'm about to use tool X. Make sure it's built first." Does that require deep wizardry in BBv2, or is quickbook.jam overly complicated? I'd think it should just be able to add a dependency on the "install dist-bin" rule invocation in tools/quickbook/Jamfile.v2, right?
I suppose there are some ways how quickbook.jam can be simplified. If you have some concrete proposals, please post them to boost-build list and I hope that João Abecasis, the quickbook.jam author, will comment.
Well, about the deep wizardry, in the general case where you want to build and use tool X, no, such deep wizardry is not needed. (I'll get back for the simpler alternative) Still, there are some specificities of quickbook that complicate matters a bit. Namely, I wanted the toolset to support on-demand compilation as well as the use of pre-compiled binaries, and I didn't want to assume that quickbook sources would always be available -- after all, this is a toolset for Boost.Build which may live outside of Boost's tree. I don't remember if any of the complexity arised from interfacing with the boostbook toolset from the outside. So, merging the toolsets could be an option to explore. There may be other places where the toolset can be simplified. I'm *not* a Boost.Build wizard and will gladly take suggestions. Anyway, as I said before, there is a simpler alternative. It works for the case where the tool will always be compiled from sources by bjam. This approach is already being used in quickbook's sketchy regression testing system. The relevant file is at boost-root/tools/quickbook/test/quickbook-testing.jam. When I wrote that, I remember looking into simplifying quickbook.jam but I didn't get anywhere... I'm still open to suggestions and comments, though. Cheers! João Abecasis