Re: Target id syntax

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-06-02 17:51:34

Ali Azarbayejani <ali_at_[hidden]> writes:

>> It's still possible to use some name-mangling scheme for main targets, but 
>> it's not that nice. I'm +0.5 towards using different separator for targets 
>> now. I'll hope to have fully formed opinion on Monday.
>
> I agree with you, but my point was that any name-mangling scheme you 
> invent is ultimately equivalent to the file pathname, so why not just 
> use the natural name?

I totally agree with Ali on this one. Any gains achieved by forcing
all names with embedded slashes to refer to targets seem to me to be
not worth it. 

> Dave and I discussed this a bit today.in person and I think I convinced 
> him about target ids based on a more detailed analysis of my use case. 
> So perhaps if Dave could summarize the conclusions from a third point of 
> view, that might help clarify the issues.

Gosh, I wish I could. I've been sick, which makes it hard to think
and remember. I'm sorry I didn't respond to this thread earlier.
All I know is that I remember having worked everything out with Ali
and there seemed to be no good reason to prohibit what he wants, and
further, some things only work elegantly if you allow it to work the
way he wants.

Ah, now I remember something! Here's the use-case that we worked out:

You have a project which unpacks some source files from an archive.
They get unpacked into a directory; there is a main target
corresponding to the directory, which depends on the archive so that
anything depending on the directory causes the archive to be
unpacked. 

# archive Jamfile
project foo ;
tar-gz libfoo-5.7.2.tar.gz ;

Other projects may use the sources that will be unpacked into
libfoo-5.7.2/ under the foo project:

project bar ;
exe bar : foo_at_libfoo-5.7.2/foo.cpp : <dependency>foo_at_libfoo-5.7.2 ;

[Yes, there's some detail missing about how to satisfy Jam's need for
existing sources, but that's a separate issue. Maybe we can do
something smart with directory dependencies]

The project also contains patches for those sources. The patches
evolve over time; you want to be able to add a patch without crawling
around in all the other projects which might use these sources to make
a change in those Jamfiles, in addition to this project's Jamfile.
What you want to do is declare a patch main target whose name is the
path-prefixed name of the file to be patched. This main target of
course depends on the file with its name.

# archive Jamfile
project foo ;
tar-gz libfoo-5.7.2.tar.gz ;
patch libfoo-5.7.2/foo.cpp ;

This main target then shadows the file called
foo_at_libfoo-5.7.2/foo.cpp, but may actually be built in a different
subdirectory, e.g. foo_at_patched/foo.cpp,

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com