Re: [boost] Re: build system suggestions

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-09 09:21:59

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

> > > directories. But why do they go to different directories? What is
> > > the reason
> > > for main target name to be present in path for target in depends on?
> >
> > Because:
> >
> > 1. the main targets may have different requirements which cause the
objects
> > to be built differently.
>
> As far as I can tell, the only thing that affects the way objects are
build
> is the set of properties used for building. Do you mean to say that free
> properties in requirements for two main targets can be different, which
> requires putting objects in different directories?

It might. Some free properties will affect link compatibility, ultimately
(e.g. #define NDEBUG).

> > 2. It's not very common to want to compile the same source file into
> > multiple executables. Maybe it happens once or twice in a project, but
it
> > accounts for a very small fraction of all source files.
>
> Over the last time, I tend to use more and more testing. This can lead to
> almost every source file been recompiled twice.

A very good practice! I guess it didn't make sense for you to put most
source files into a static library?

> > 3. static libraries provide a simple mechanism to achieve that.
>
> Yes, but it's more like a artifical mechanism, or workaround.

Two ideas:

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!!! 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.

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).

> From www.m-w.com:
> Main Entry: cap*tious
> 1 : marked by an often ill-natured inclination to stress faults and raise
>   objections

Sorry, I should've looked that up myself. You learn something new every
day...

> > I'm satisfied with anything that almost never recompiles needlessly.
It's
> > pretty hard to detect exactly which things might need to be recompiled
> > under all circumstances, and IMO not worth the effort.
>
> I'll need to think about ways of implementing it and needed effort. So far
it
> seems like two-fold saving in compilation time can be achieved.

Let me know what you think of the above ideas. I think the first one is most
promising, FWIW.

-Dave