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
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
>>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
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)
>>>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:
> 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
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 '/'!
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