Re: [jamboost] Target id syntax

From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-06-03 09:53:02

Vladimir Prus wrote:
> Hi Ali,
> 
> 
>>>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.
> 
> 
> I meant something different. Whenever I use external thing, I don't use 
> sources from it directly, but rather libraries. In your use case, you seem to 
> be using specific source files.

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.

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.

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

--Ali