Boost logo

Boost-Build :

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?



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at