From: Hugo Duncan (hugo_duncan_at_[hidden])
Date: 2003-10-22 12:49:40
--- In jamboost_at_[hidden], Vladimir Prus <ghost_at_c...> wrote:
> Hugo Duncan wrote:
> > --- In jamboost_at_[hidden], Vladimir Prus <ghost_at_c...> wrote:
> > > David Abrahams wrote:
> > > > > Or hash the directory name and only have something like:
> > > > >
> > > > > gcc/1234567/...
> > gcc/release
> > gcc/debug
> I.e. without "bin" and main target name. Well, "bin" is just a way
> all built products under one directory.
Sorry, I meant keeping the bin and the main target name but
without the rest. ie replacing 1234567/... in Dave's example
with "release". This is probably ok for executables, but somewhat
resrictive for libraries. Anyway, I was really just trying to
suggest some scheme to avoid having to wade through directories
with cryptic names.
> > I can see that might cause problems if you change the definition
> > of the options used in a specific build.
> Hmm... interesting question. The main target name is used to handle
> situation when a target has some property which can't be represented
> in path, e.g. free property. But this is only a problem is target
can be built
> twice with different values of that free property. And if a target
> only by one main target, it's always built with the same properties.
> Maybe, the main target name can be just removed from target path?
I guess you could write the options used to a file (or a hash number
generated from the options) and then compare the file's contents with
the options for the current build.
As I understand it the long directory names are there to:
i) to maintain consistency of binary objects.
ii) be able to keep seperate objects for seperate builds.
At the moment the directory namimg is driven by the first of these,
which is usually overkill for the second aim.
ie I usually build a release, debug and profile version of an
executable. to solve i) and ii) I need three directories. At the
moment I get a deeply nested directory structure to define these
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk