Re: [jamboost] Target id syntax

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-02 02:48:30

Ali Azarbayejani wrote:
> > Ali Azarbayejani wrote:
> >> In the current system, how can you possibly declare a patched file
> >> without making it a main target? I want the user to be able to declare
> >> something like
> >>
> >> extract foo : foo.tar.gz ;
> >> patch foo/b : patches/foo/b : <dependency>foo ;
> >
> > If you want this functionality for end users, then I agree, "foo/b" looks
> > right name. I have one question left: why the user is expected to update
> > 'foo/b'. Is it because either "foo.tar.gz" or the set of patches can
> > change while user is working on a project?
>
> I don't understand the question. It's true that either the tarfile or
> the patches can change (the tarfile normally doesn't, but the patches
> normally may). But that seems to me irrelevant with regards to why
> foo/b needs to be a main target.

The question really was: why build system should handle patching --- why not 
extract/patch once, and live with it. You've answered my question.

> The user needs to convey the information that 'foo/b' requires patching,
> so such a declaration is necessary. The only way I know to represent
> the declared information in the BBv2 system is by creating a main target.

Since we're speaking about the right way, not what's possible currently, I 
might imagine something like

patch-tree patch-foo : foo patches ;

So, when the user gets new patches, he would run 

bjam patch-foo ;

and the sources will be updated.

The situation where "foo/b" is both a source and a target resembles me what I 
had with gettext support (that I've did locally for V1). The translations 
file is converted into machine form. But the translation files is itself 
updated from sources. The way I did it, translation files was updated from 
sources every time, and that was troublesome: I don't want them updated 
unless I'm willing to correct translations.

So, I've decided that in V2, translations will only be updated after explicit 
request. In the case above, it probably makes some sense too. Imagine:
user has locally modified "foo/b", and new version of patch for the file 
arrives. He rebuilds and "foo/b" is patched. Original version is stored.
Another version of patch arrives, he does the same again, and now the original
version of file is gone. I'm not sure this is real problem 

> Also, the extracted or patched file must be a main target because other
> external projects will want to use these extracted and patched files and
> there's no way to properly refer to them if they are not main-targets.

That's an argument! I still wonder, however:
1. Why other project need to access patches files. Can you explain in more 
detail?
2. The same effect can be achieved by subprojects: i.e. placing Jamfile in foo 
and declared main target "b" there. It might not be ok for your use case. The 
problem is that "foo/b" looks like you declare a target in different 
directory or different project. 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?
3. Do users define all those main target manually? If not, probably the best 
solution is to define one main-target to apply all patches, and make external
targets depend on specific file, not on main target. That would still require 
separating target and project with something else than "@".

> >> > I'm still to be persuaded that targets should have slashed..
> >>
> >> I'm still to be persuaded that you can implement the above example
> >> without multiple main targets that have the same base name. If you
> >> can't, then it would be a hard argument to invent some way of
> >> distinguishing them other then their pathnames, which are already
> >> guaranteed to be unique.
> >>
> >> Let me know your prognosis of the above, or if you still need more
> >> clarification of the example.
> >
> > 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?

The remaining 0.5 is due to concern that another separator will make worse 
user-interface, for the sake of not very common use cases.

> 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.

I'd be interested in hearing his opinion.

> Thanks and have a good weekend,
> --Ali

Thanks,
Volodya