From: João Abecasis (jpabecasis_at_[hidden])
Date: 2007-01-14 23:08:37
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'
[snip]
> 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
this case,
> it's emitted due to quickbook.jam bug, and I don't think there's much
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