--- !ditz.rubyforge.org,2008-03-06/issue title: merge duk_features.h and duktape.h, creating the header from parts during build? desc: |- The public header needs some type declarations which depends on platform and compiler. These are pretty complicated especially for the non-C99 case, and currently need to be duplicated between duktape.h and duk_features.h because user code only includes duktape.h. This doesn't really work well, because there is a tendency for things to get sucked in from duk_features.h into duktape.h. Perhaps the cleanest move would thus be to merge duk_features.h, duk_features_sanity.h, and duktape.h, building a single duktape.h for both internal and external use from individual header parts. For the src-separate build the header can be a wrapper which includes multiple parts in sequence. For the merged build the header should be reasonably clean so perhaps it should be merged with something other than util/combine_src.py. The merged header should clearly indicate which sections are defining the public API and which sections are not. The downside of this approach is to complicate the duktape.h header a great deal; this is bad because it was originally intended to be easily readable. The upside is that all platform detection and feature resolution will be shared, so that API definitions will be aware of features in use. For example, if file I/O is disabled, file related API calls can be converted into #error preprocessor statements or empty code. type: :task component: duk release: v0.11 reporter: Sami Vaarala status: :closed disposition: :fixed creation_time: 2014-05-04 20:42:26.183606 Z references: [] id: 1d99f229ebb0f0b3925f41125ff9b5f9823aeb9e log_events: - - 2014-05-04 20:42:26.833851 Z - Sami Vaarala - created - "" - - 2014-05-05 12:47:58.990221 Z - Sami Vaarala - closed with disposition fixed - ""