Re: [boost] Re: build system suggestions

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,
ultimately
> > (e.g. #define NDEBUG).
>
> Ok, seems like the definition of free features should be revised. See
below.

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
to
> > 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
substantially.
> > 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
suppose,
> > 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
common
> practice.

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,
so
> > that they can be linked in to other targets -- I think raw Jam is meant
to
> > be usable in this way. The approach would have two benefits:
> >   a. No intermediate static library creation step (a trivial issue;
hardly
> > 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
targets,
> > 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
special
> > rules which allow these first-class targets to be created
"transparently",
> > as opposed to explicitly. That would save users from  writing
"make-like"
> > 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:
"Give
> me src/..../foo.cpp, compiled with this property set". Yet how will this
> interact with free properties?

Good question.

> After some thought, I formed some alternative definition of free property.
It
> is that free property might affect link compatibility, but what's
important
> 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
targets
> 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
could
> possibly encode all the properties, we can collapse all the free
properties
> in name of main target object target belong to. I see this as having
> considerable convenvience, but nothing else. Therefore, it could be
possible
> to use rule that build objects, but yet I don't see many advantages now,
and
> 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
guess.
> I would like to know your opition.

I hope what I've written helps to clarify that for you.

Regards,
Dave