From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-05-17 03:38:37
On Tuesday 19 February 2008 22:16:59 Juergen Hunold wrote:
are you still planning to make any adjustment to this patch? I understand you
planned to make some, but not sure what happened about that. I probably
can pick this patch up if you're out of time for now.
> Sorry, I was without internet over the weekend and got swamped with work
> on Mondy...
> On Sunday 17 February 2008, Jurko Gospodnetiæ wrote:
> > 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...
> Me neither ;-))
> > * 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.
> Well, I just tried to improve the patch from Volodya. I think that the
> full build path is not available in generators.jam. I'll have to check
> > * 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?
> This also depends on the issue above.
> > * 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 failure flag.
> I'll check this
> > * 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.
> Ouch. This is on Windows, right ?
> > --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... :-(
> I fear this is way beyond my current (read: nearly non-existant)(b)jam
> and Boost.Build knowledge :-(( And the recent thread about this issue
> endet with no clear solution, at least to me...
> > * Typo in comment in generators.jam.
> > s/with the same in two/with the same name in two/
> Will be fixed.
> > Hope this helps.
> Sure. I now know where to look. But please don't expect too much, I'm
> struggling to get some time to get a deeper understanding of the beast.
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