Re: [jamboost] Target id syntax

From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-06-02 11:10:15

Vladimir Prus wrote:
> 
>>So "patch-tree" can be implemented in terms of "patch-file". For
>>modularity and maintenance reasons, this is desirable. Thus with the
>>"patch-tree" high-level rule, the individual files are not expressed
>>explicitly, but they would still end up as main-targets if "patch-tree"
>>is implemented with "patch-file". 
> 
> 
> IWO, "patch-tree" would just gather the names of files, and invoke 
> "patch-file"?

yes, that's the way i implemented it. it doesn't have to be that way, 
but it is better for maintenance.

>>>1. Why other project need to access patches files. Can you explain in
>>>more detail?
>>
>>Yes. In my modular structure, I have one kind of module ("Package
>>Module") that is responsible for unpacking and patching elements of a
>>tarfile and another kind of module ("Software Module") that is
>>responsible for building libraries and/or executables. A Software
>>Module doesn't care whether its source files come directly from the
>>repository or whether they come from a Package Module. Thus, to build a
>>library from source that comes from a packaged tarfile, a Software
>>Module must reach into the Package Module to obtain the final sources
>>(extracted and patched).
>>
>>In BB terminology, Package Module and Software Module are different
>>kinds of "project". And they are not necessarily related (although
>>currently, the related Software Modules belong to the Package Module).
> 
> 
> Thanks for explanation. As I understand, making the external tarred/patched 
> project into real V2 project (which main targets for some libraries) is not 
> possible?

I'm not sure what you mean. The project that un-tars and patches IS a 
real V2 project.

Do you mean the thing that is being un-tarred in the first place? It is 
not possible in general because these come from dozens of third-party 
sources. N.B. it is a requirement of our system that these tar files 
are reposited *unmodified* so that there is a traceable path from 
distribution to compiled library.

Conceivably, if all third-parties wrote compatible Jamfiles for their 
distributions I'd be all set, but these "third-parties" don't seem to 
adhere to my requirements, so I'm stuck with writing additional Jamfiles 
on my end.

>>>Further, there's another question: if you
>>>possible have (using @ to separate target name)
>>>
>>> location_at_foo/b
>>> location/foo_at_b
>>>
>>>is there potential for confusion?
>>
>>I don't think there's confusion.
>>
>>The first one is target "foo/b" in project "location/Jamfile" or file
>>"foo/b" relative to project "location/Jamfile" (i.e. "location/foo/b").
>>
>>The second one is target "b" in project "location/foo/Jamfile" or file
>>"b" relative to project "location/foo/Jamfile" (i.e. "location/foo/b").
>>
>>This seems crystal clear to me. I don't think that it is a problem that
>>file "location/foo/b" can potentially be referred to in several ways
>>(also "._at_location/foo/b"), implying membership of a source file in
>>multiple projects at once. It would be unusual to have
>>"location/Jamfile" AND "location/foo/Jamfile" AND be referring to file
>>"location/foo/b" as a source of both projects, but, on the other hand,
>>it is conceivable that you would WANT to have a source serve two
>>separate projects and the notation is crystal clear.
> 
> 
> Probably, I'm overestimation possible confusing. Let's see if we can agree on 
> new target id syntax. You've proposed:
> 
> <target-or-filename>
> @<project>[@<target-or-filename>]
> 
> Which in essense, means a second separator for target.
> 
> I'd suggest:
> - using '%' for the second separator
> - allow current slash separated syntax as the last fallback, until we roll M4.
> 
> What do you think?

Actually, I don't see a point for the "@" at the beginning...I was just 
following the current syntax which I don't entirely understand. Is 
there a reason for the initial '@'? If not, the syntax could be as 
simple as

<target-or-filename>
<project>[@<target-or-filename>]

N.B. The specification "<project>" won't be confused with 
"<target-or-filename>" in any meaningful way because the former must be 
a directory name that contains a Jamfile....there is some potential 
ambiguity here, but I don't know if it's worth adding extra notation for.

I don't care what the separator '@' is as long as it's not '/'!

--Ali