Re: [boost] Re: build system suggestions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-10-17 03:58:24

Hi David,

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

Ok, seems like the definition of free features should be revised. See below.

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

This could be done, but wouldn't be a natural decision.

> > > 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!!! 
O! I like this too.

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

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

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. Indeed, it would scarcely make sense to 
build one target with different "unsigned-char" option, simply some targets 
want a particular value. 

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. 

Please note that my discussion of free features above is somewhat of a guess. 
I would like to know your opition.

Regards,
Vladimir