Re: Automatic creation of target directories

Ingo wrote:
> In my experience it's not a wise decision to use paths
(be they relative or
> absolute) in jam for anything but directories (which is
probably also why
> there's a FDirName rule, but no FFileName). Grist works
well for avoiding
> name clashes, and referring to targets independently of
their location is
> one of the coolest of jam's features, IMHO.

This is ok for the traditional *nix style build approach.
But for
various reasons (primarily because we deal with content
files besides
just source code), in our shop, everything is always refered
to by
"apsolute" paths (not absolute as in D:..., but
relative to one fixed
workspace folder). When you have it set up that way, it is
much
simpler to move things across directories, because there is
no single
#include "../something.h" anywhere in the code,
and there are other
upsides as well. I didn't see a single downside yet. We
support the
traditional way as well, e.g. for OSS pieces and external
libraries
that we include in our projects, but for our own code we
have only one
include dir - root of the workspace. 

Cheers,
Alen

_______________________________________________
jamming mailing list  -  jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

Hi. I agree with your approach, ours is similar...

Ok, we use two paths instead of one, one for our source, one
for 3rd
party source. As we always use <> for non-local
includes and "" for
local includes, I've modified jam's HdrRule to take this
into account.
I.e. it doesn't use the search path for ""
includes (as you normally
would) since we have headers like "Math.h" and
<Math.h>, one which is
ours and one which isn't. As some local includes use
subdirectories,
i.e. "../includeme.h" - I've made jam add a
variable on a target
called LOCATED which I then use during HdrRule to calculate
the
correct single path for a relative include (based on it's
parent, as
you would expect).

But I suppose using just one root path and relative paths
off it would
make it just as easy, we just didn't want to go quite that
far. ;)

Like you, we're building both assets and code. We produce
data sets
for pc, xbox and playstation. To speed up our builds we use
Incredibuild with jam to distribute it, it's great.

Craig.

On 5/10/07, Alen Ladavac <alenl-mlcroteam.com> wrote:
> Ingo wrote:
> > In my experience it's not a wise decision to use
paths (be they relative or
> > absolute) in jam for anything but directories
(which is probably also why
> > there's a FDirName rule, but no FFileName). Grist
works well for avoiding
> > name clashes, and referring to targets
independently of their location is
> > one of the coolest of jam's features, IMHO.
>
> This is ok for the traditional *nix style build
approach. But for
> various reasons (primarily because we deal with content
files besides
> just source code), in our shop, everything is always
refered to by
> "apsolute" paths (not absolute as in D:...,
but relative to one fixed
> workspace folder). When you have it set up that way, it
is much
> simpler to move things across directories, because
there is no single
> #include "../something.h" anywhere in the
code, and there are other
> upsides as well. I didn't see a single downside yet. We
support the
> traditional way as well, e.g. for OSS pieces and
external libraries
> that we include in our projects, but for our own code
we have only one
> include dir - root of the workspace. 
>
> Cheers,
> Alen
>
> _______________________________________________
> jamming mailing list  -  jammingperforce.com
> http://maillist.perforce.com/mailman/listinfo/jamming
>
_______________________________________________
jamming mailing list  -  jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming