From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-17 12:55:52
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
> > It might. Some free properties will affect link compatibility,
> > (e.g. #define NDEBUG).
> Ok, seems like the definition of free features should be revised. See
I'm open to a revision...
> > 1.For main targets with no free-feature requirements, I suppose that it
> > would be fine to build all objects into a common pool. In other words:
> > exe a : a.cpp b.cpp ;
> > exe b : b.cpp c.cpp ;
> > exe c : c.cpp d.cpp : <define>SOMETHING ;
> > you could avoid recompiling b.cpp in this case, but you could not avoid
> > recompiling c.cpp. This would normally not be a practical optimization
> > take advantage of, because practically every target has <include>
> > requirements. On the other hand, incorporating your idea of project and
> > subproject requirements into the design reduces this problem
> > I LIKE THAT!!!
> O! I like this too.
Great; we will use this design.
> > There would still be a limitation that the same source file
> > used from two different subprojects would be recompiled:
> > # bar/Jamfile
> > exe a : ../foo/b.cpp ;
> > The above could not share b.o with the foo subproject... unless, I
> > foo and bar have the same subproject requirements. I hope you don't care
> > about that too much.
> Actually, no. Stealing objects from different subproject is hardly a
We could still make it work for some practical cases. It might even be
simpler to do that way.
> > 2. It should be possible to add a rule which just builds object files,
> > that they can be linked in to other targets -- I think raw Jam is meant
> > be usable in this way. The approach would have two benefits:
> > a. No intermediate static library creation step (a trivial issue;
> > worth mentioning).
> > b. On some platforms, static libraries are apparently ineligible for
> > incorporation into a dynamic library, if the component object files are
> > supposed to export symbols. If the object files were first-class
> > they might be able to be reused and linked both ways. I'm not really
> > confident of this, however.
> > If you find yourself needing these objects often, you could define
> > rules which allow these first-class targets to be created
> > as opposed to explicitly. That would save users from writing
> > rules which explicitly build the .o from the .cpp and then the
> > exe/lib/whatever from the .o file(s).
> This is somewhat harder to implement and results of this approach are less
> clear to me. Surely, it is conceptually more clear to be able to say:
> me src/..../foo.cpp, compiled with this property set". Yet how will this
> interact with free properties?
> After some thought, I formed some alternative definition of free property.
> is that free property might affect link compatibility, but what's
> is that free property is supposed to remain the same for any given main
> target/simple-properties combination.
How is that different from what we currently have?
> Indeed, it would scarcely make sense to
> build one target with different "unsigned-char" option, simply some
> want a particular value.
Maybe I misunderstand you. What I think you're saying is that a main target
(e.g. a static library) should only ever be built with one setting for
whether char is a signed or unsigned type. I'm not sure if you see the
signedness of char as a free feature or not. I would not call it a free
feature, since it is a fundamental aspect of the ABI, though I can see how
you could "get away" with treating this particular feature differently. If I
understand you correctly, then I think I disagree, because the static
library may be linked into different executables, and the executables may
have different "signedness of char" requirements.
> With this definition we can conclude that, thought path to each target
> possibly encode all the properties, we can collapse all the free
> in name of main target object target belong to. I see this as having
> considerable convenvience, but nothing else. Therefore, it could be
> to use rule that build objects, but yet I don't see many advantages now,
> your first idea looks better.
Ah, maybe this whole "redefinition of free" idea is moot in light of our
agreement to pursue option 1? That would be a nice simplification ;-)
> Please note that my discussion of free features above is somewhat of a
> I would like to know your opition.
I hope what I've written helps to clarify that for you.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk