From: Jurko Gospodnetiæ (jurko.gospodnetic_at_[hidden])
Date: 2008-02-17 17:04:22
> Reviews of the proposed changes are welcome.
I played with this a bit and below are some comments. Note that I did
not go deep into any implementation details as I do not fully comprehend
how all the changed parts work together...
* Could it be made to work the same even when source paths are given
as absolute names but still point to inside the source-location tree?
Currently it treats such paths as it did before - just placing them in
the top-level build folder.
* Related to the previous comment, if you have source-location /A/B/C
and specify a source file as ../C/X/x.cpp, could it correctly create the
obj target in X/x.obj instead of just x.obj?
* Is there a better way to report from path.relative that the given
'child' folder is not actually a child to the given 'parent' folder than
returning a string 'not-a-child'. OK, I know I'm nitpicking, but
'not-a-child' might be a valid folder name. How about returning a pair
of (success-flag, value) instead of using up such a folder name as a
* One project I tried testing this on had quite a deep source folder
hierarchy and enabling this behavior causes its build to fail due to the
used target folder path becoming too long. --abbreviate-paths option
saved the day this time but it could quite easily not have been enough.
What can be done about this anyway? Properties themselves sometimes
cause target folder hierarchies to become too deep and this only
aggravates the problem... :-(
* Typo in comment in generators.jam.
s/with the same in two/with the same name in two/
Hope this helps.
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