Boost logo

Boost-Build :

From: Eric Woodruff (eric.woodruff_at_[hidden])
Date: 2008-04-02 12:51:13


>
> Let's backtrace a bit. Does requesting files in 'dist' on the command line
> work now?
It does, but only for an install target in the project root, not for an
install defined in a sub directory. I made a directory called src/ and
created this Jamfile:

    explicit goodbye ;
    make goodbye : : @touchfile ;
    install $(DIST) : goodbye ;

    actions touchfile {
            mkdir -p $(<:D)
            touch $(<)
    }

>From the project root, bjam dist/goodbye doesn't know how to make
<e>dist/goodbye

> So, for this to work you need to add INCLUDE on the same targets that are created
> above.
The alias grist is <e>dist/hello which works when the install target is
defined like this:

    install dist : hello ;

But if I use a path-constant and define DIST like this:

    path-constant ROOT : . ;
    constant DIST : $(ROOT)/dist ;
    install $(DIST) : hello ;
      

The grist (when looking -d+3) actually becomes
<e>/home/eric/workspaces/tar/dist/hello and the one for the src/
directory is similar, but different
<p/home/eric/workspaces/tar/dist>goodbye.

So I can see why this couldn't be expected to work on the command-line
in all cases. But how do I know what grist to generate for these
includes, if they can be absolute or relative, and p or e?

One thing I can do is reference the same $(DIST) absolute path when
invoking tar, rather than by the unqualified 'dist'; this will probably
be required. However, I don't know how to generate a <p > style grist.

BTW, are you going to apply the bind STYLESHEET fix to xsltproc.jam on
the trunk?

Thanks,

Eric

Vladimir Prus wrote:
> On Wednesday 02 April 2008 10:54:18 Eric Woodruff wrote:
>
>> Volodya,
>>
>> OK, I checked out the trunk versions of jam and build/v2. I then figured
>> how to write the generator for tar, I think. Here's the complete output
>> I get now:
>>
>
> Let's backtrace a bit. Does requesting files in 'dist' on the command line
> work now?
>
>
>> I've attached my project files, including the rudimentary tar.jam.
>>
>
>
>> � rule process ( target : matches * : binding )
>> � {
>> � � local target_path = [ NORMALIZE_PATH $(binding:D) ] ;
>>
>> # � �NOCARE $(matches) ;
>> � � INCLUDES $(target) : $(self.includes:G=)/$(matches) ;
>> � � SEARCH on $(matches) = $(target_path) $(self.includes:G=) ;
>> � �
>> � � scanner.propagate $(__name__) : $(matches) : $(target) ; � �
>> � }
>>
>
> Are you sure that
>
> $(self.includes:G=)/$(matches)
>
> is right? All bjam targets created by Boost.Build have some grist.
> For reference, here's how virtual-target.jam creates 'alias' targets
> can are used to request specific file on the command line:
>
>
> # For a real file target, we create a fake target depending on the
> # real target. This allows us to run
> #
> # bjam hello.o
> #
> # without trying to guess the name of the real target. Note that the
> # target has no directory name and uses a special <e> grist.
> #
> # First, that means that "bjam hello.o" will build all known hello.o
> # targets. Second, the <e> grist makes sure this target won't be
> # confused with other targets, for example, if we have subdir 'test'
> # with target 'test' in it that includes a 'test.o' file, then the
> # target for directory will be just 'test' the target for test.o
> # will be <ptest/bin/gcc/debug>test.o and the target we create below
> # will be <e>test.o
> DEPENDS $(target:G=e) : $(target) ;
> # Allow bjam <path-to-file>/<file> to work. This won't catch all
> # possible ways to refer to the path (relative/absolute, extra ".",
> # various "..", but should help in obvious cases.
> DEPENDS $(target:G=e:R=$(path)) : $(target) ;
>
> So, for this to work you need to add INCLUDE on the same targets that are created
> above.
>
> - Volodya
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
>
>



Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk