<jmason> so, part of the rules project thing is that it's a different SVN
tree, not tied to the code
<jmason> (this will allow us to use rules-project stuff with older
releases as well)
<jmason> but it also means that we had to split the current ruleset into
stuff that was "code-tied", dependent on specific implementation code like
eval tests, and "independent", ie. body rules etc.
<jmason> "code-tied" are what's current in rules/
<jmason> "indepedent" are what's in rulesrc/core/*.cf
<jmason> and the problem now is that we have left the "code-tied" stuff in
the rules dir, and reused that dir as the output directory for the build
process also
<jmason> therefore it's impossible for a script to easily tell if
"rules/20_foo.cf" is (a) a code-tied source rules file, or (b) a
"compiled" independent rules file
<jmason> which also means that "make clean" won't clean up "compiled"
rules files either
<jmason> we need to have some way of telling the code-tied rules from the
compiled independent rules.  either we can use a new, different suffix for
one of those classes, or add a new "rulesrc/" directory, for the source of
the code-tied rules, and compile them alongside the independent rules as
well in the mkrules step


So I think to, expand on that, we should either:

- either change it so that the compiled rules files wind up with
  a new suffix, so they can be differentiated from the source
  rules in "rules"; or

- add a new rule source dir for the code-tied ruleset source files,
  and compile them alongside the rules project source files into
  "rules".

let me know what you all think.

--j.

Reply via email to