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

  

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build