issue-1d99f229ebb0f0b3925f41125ff9b5f9823aeb9e.yaml

--- !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 <sami.vaarala@iki.fi>
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 <sami.vaarala@iki.fi>
  - created
  - ""
- - 2014-05-05 12:47:58.990221 Z
  - Sami Vaarala <sami.vaarala@iki.fi>
  - closed with disposition fixed
  - ""