Re: [jamboost] Target id syntax

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-04 04:34:48

Ali,

> I guess I see "real V2 project" more generally then just in terms of a
> C++ project...could be a tarfile extraction, could be a code generator
> (we have one project here that uses a commercial package to generate C++
> sources...then we have to compile it), or anything else a user might
> dream up to use it for. Currently, I use Make for producing a lot of
> things, including recipes for generating experimental image processing
> results. Similarly, should be able to use BBv2 to build anything, not
> just libraries and executables.

> In the case of the tarfile module the "C++ source files" are not really
> "sources", conceptually....they are final "targets" as far as that
> particular module is concerned. The external C++ library module then
> uses these tarfile final targets as its sources. Et cetera.
>
> So, yes, I am using C++ source files externally, because in my system I
> have separated the functionality of managing the tarfile from the
> functionality of building and using C++ libraries (you see, extracting
> and patching could also apply to Java code, Python code, or some
> documents, etc). And, certainly it is possible to do it a different
> way, but I believe that this way is easier for my users to use and
> maintain. In any case, I think it should be possible for external
> projects to use whatever targets another project chooses to define,
> including C++ source files.

So, to summarize:
1. The project which extract tarfile may extract all possible kinds of 
targets, and it's reasonable to use them directly from other project.
2. The rule for unpacking tar is inplemented in terms of "patch-file", for 
maintainability, and therefore, must use main target name which contains 
slashes?
3. Using sub-Jamfile in "foo" to declare extracted file "foo/b" is not an 
option, because you should not change existing tree 

That makes good rationale for why main target must contain names.

> It might clarify things if you understand that my users are not going to
> be writing the final Jamfiles directly, so they won't be making choices
> like, "should I put the library in this project or a different
> project?". There is already one protocol for specifying Libraries and a
> separate protocol for specifying Packages (i.e. extracted and patched
> tarfiles). Currently this protocol sits on top of Makefiles/GNUMake and
> I would like to merely replace the underlying implementation with
> Jamfiles/BBv2/BoostJam. So I am concerned with making sure BBv2 meets
> existing requirements of a higher level system, even if there might be
> reasonable alternatives at a lower level.

OK. 

> > The point of @ at the beginning is that project can be referred in two
> > ways: - using Jamfile directory
> > - using project-id
> > To indicate that project-id is used, we need "@" symbol.
> >
> > So the actual grammar is
> >
> > <target-or-filename>
> > <project-location>[@<target-or-filename>]
> > @<project-id>[@<target-or-filename>]
>
> Do we really need to explicitly distinguish formal project-id from
> project-location? Can't we use the same logic as that proposed for
> target-or-filename i.e., if the project-id exists, then use the
> project-id, otherwise interpret it as a path?
>
> Can you think of an example of where there would be a meaningful
> ambiguity? Surely there was some motivation originally for making this
> distinction, but I wasn't around then. Can you remember an example?

That discussion happened a long time ago --- more than an year, and I don't 
really remember the details. For me, project-id without "@" looks confusing, 
but I can't explain why. Let's see some examples

/boost/filesystem%filesystem	--- OK, absolute project id.
helpers%i18n --- OK, might be target i18n in
directory helpers
lvk%mon --- OK, might be target mon in 
project "lvk".

I can see two possible problems:
1. If you declare project "helpers" somewhere, the meaning of the second id 
changes.
2. It not obvious where to look for target, if you see second or third id. 

OTOH, I can't tell how important they are. So --- I'll implement the scheme 
without separate "@" for project-id. In future, we can always add "@" back.

- Volodya

>
> --Ali
>
>
>
>
> To unsubscribe from this group, send an email to:
> jamboost-unsubscribe_at_[hidden]
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/