|
Boost-Build : |
From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-08 07:52:02
----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>
> David Abrahams wrote:
> > I like the name "GLOB", if the primitive is going to actually do
globbing.
> >
> > The very simplest primitive would be one that returns the names of all
> > files in a given directory. We could then implement GLOB in Jam rules,
> > using regular expressions. In general I have been in favor of making the
> > built-in rules as primitive as possible and doing as much as is feasible
at
> > the interpreted level.
>
> I've implemented GLOB builtin recently. The question is if we really need
it
> now? I ask just because I never desperately needed GLOB myself and adding
new
> features without discussion might be dangerous, especially if Boost.Jam
> should be in sync with Perforce Jam (which is talked about in other
thread).
That's why I am in favor of the simplest primitives. In general, this
results in the smallest 'C' code changes with the fewest maintenance
problems, and the fewest opportunities for Perforce to decide they don't
like the way we've implemented it. Adding a new builtin rule, in general, is
much less intrusive on the code than many of the features I've added to the
core interpreter like modules, file/line tracing, argument lists...
> GLOB works the following way:
> 1. It takes one arguments (might take sevaral and process then all)
> 2. It splits the arguments into directory name and everything following
it.
> 3. The second part is taken to be wildcard. Filenames in named directory
are
> matched against the wildcard, and the list of those which matches is
returned.
>
> For example
>
> [ GLOB subdir/* ]
>
> might return
>
> subdir/a.c subdir/b.c
>
>
> If it is decided that GLOB is needed, I'll write more tests, document the
> feature and check it in. Something that works (but needs cleanup)
> is in
> http://chronos.cs.msu.su/~ghost/projects/jam_src.tar.gz
> http://chronos.cs.msu.su/~ghost/projects/jam_src.diff
I've not looked at your implementation, but I still think a rule which takes
a single directory name and returns all the filenames in that directory
would be a better way to go. Just as powerful, ultimately, and simpler
source code.
-Dave
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