[jamming] Automatic creation of target directories

[Craig Allsop]

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-ml at croteam.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  -  jamming at perforce.com
> http://maillist.perforce.com/mailman/listinfo/jamming
>