From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-02 03:32:15
On Wednesday 01 December 2004 15:45, David Abrahams wrote:
> Vladimir Prus wrote:
> > I think the problem is that
> > 1. We can't mark a specific group in regexp as "unimportant". In
> > Perl/Python, regexp can have "non-capturing paranthesis",
> > >>> r = re.compile("(?:foo|bar)(.*)")
> > >>> m = r.match("foo10")
> > >>> m.group(1)
> > '10'
> > but I don't think bjam's regexps support that
> > 2. Bjam passes only the first matched parenthesised group to the scanner.
> > Looks like your hack is the simplest solution.
> I'm not sure it will work, though :(. Are you?
Yes. The bjam code allows several regexps to be specified. It tries all of
them, and for those which match, adds first matched group to the list of
strings which is passed to header rule.
I've just checked (on example/customization), that two regexps work.
> The most proper solution would be to provide an additional (outer)
> virtual function in the scanner class that can be used to get more
> control over exactly what gets examined when scanning. It might be
> neccessary to change the bjam core to do that, though. And maintaining
> scanning speed is important there.
Yes, speed could be a problem, so we must be carefull.
BTW, if we make bjam return all matched groups, it will affect C, which uses
"#[ \t]*include[ ]*(<(.*)>|\"(.*)\")" ;
which has three groups (two of them nested), so we'll get tree strings for
Doing this property requires profiling, so maybe you could try specifying
three regexp in the meantime?
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