digitalmars.D - Features for a D 'header file' generator?
- Dave (36/36) Nov 12 2005 With a start from dmdfe (http://home.comcast.net/~benhinkle/dmdfe/), it ...
With a start from dmdfe (http://home.comcast.net/~benhinkle/dmdfe/), it looks feasible to create a header file generator using the reference compiler front end. Here's what's been tried so far: a) Emit legal source code for relavant declarations and definitions at any nesting level (*). b) Emit template declarations so they can be mixed with non template code in the same module and also imported/used by other 'header' files (*). c) Emit function bodies for 'inlinable' functions and methods (so the compiler can inline from header file imports - important for things like math libraries). d) Exclude private members if they are not referenced elsewhere (except in template declarations where everything is emitted). However, this could cause subtle and hard to find and fix bugs related to things like classinfo and member offsets (and make the header generator quite a bit more complicated). e) Exclude template declarations and/or template members not used (instantiated) in the same module (excluding unused template members hasn't been tested but looks possible). f) Exclude all function bodies, private members and template declarations. This would generate a header that is basically just a stub for the binary only. I guess the features will come down to if the header files could be used as both source code and 'stubs' for binaries, or for just stubs. For example, for a large general purpose library like phobos or Ares, I think +a, +b, +c, -d, -e, -f would be the feature set. Or, would just option f) be what is expected, and full source code could be shipped for things like math and template libraries? The goal would be to create a general purpose header generator that would make it very convenient to generate header files w/o adding a bunch of option switches to the tool or compiler itself. An assumption has been made that emitting source code for just 'inlineable' (typically small and simple) functions would be acceptable even for proprietary libraries. Is this a poor assumption? Opinions? Thanks, - Dave * An exception found so far is some typeid(...) because some build-in type information is part of the "backend" and is not included in the compiler source code.
Nov 12 2005