1. 17 Mar, 2015 2 commits
  2. 16 Mar, 2015 11 commits
    • Richard Levitte's avatar
      Do not keep TABLE in version control. · e3c15964
      Richard Levitte authored
      
      
      TABLE was always a debugging tool, and permitted everyone to see the
      effect of changes in the string-format configs.  The hash-format
      configs being much more readable, distributing TABLE becomes much less
      necessary.
      
      Being able to produce a TABLE is kept, however, as it still is a
      useful debugging tool for configs, what with multi-level inheritance
      and all.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      e3c15964
    • Richard Levitte's avatar
      Configuration cleanup: personal configs · a5250ec0
      Richard Levitte authored
      
      
      Move obviously personal configurations to personal files.
      
      Note: those files should really not be in the main repo at all
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      a5250ec0
    • Richard Levitte's avatar
      Updated TABLE · d52dcf8d
      Richard Levitte authored
      
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      d52dcf8d
    • Richard Levitte's avatar
    • Richard Levitte's avatar
      Change all the main configurations to the new format. · 5e1b2353
      Richard Levitte authored
      
      
      As part of this, remove some levitte examples that never were relevant.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      5e1b2353
    • Richard Levitte's avatar
      Rethink templates. · b1245529
      Richard Levitte authored
      
      
      Because base templates express inheritance of values, the attribute is
      renamed to 'inherit_from', and texts about this talk about 'inheritance(s)'
      rather than base templates.
      
      As they were previously implemented, base templates that were listed
      together would override one another, the first one acting as defaults for
      the next and so on.
      
      However, it was pointed out that a strength of inheritance would be to
      base configurations on several templates - for example one for CPU, one
      for operating system and one for compiler - and that requires a different
      way of combining those templates.  With this change, inherited values
      from several inheritances are concatenated by default (keep on reading).
      
      Also, in-string templates with the double-curly syntax are removed,
      replaced with the possibility to have a configuration value be a coderef
      (i.e. a 'sub { /* your code goes here */ }') that gets the list of values
      from all inheritances as the list @_.  The result of executing such a
      coderef on a list of values is assumed to become a string.  ANY OTHER
      FORM OF VALUE WILL CURRENTLY BREAK.
      
      As a matter of fact, an attribute in the current config with no value is
      assumed to have this coderef as value:
      
          sub { join(' ', @_) }
      
      While we're at it, rename debug-[cl]flags to debug_[cl]flags and
      nodebug-[cl]flags to release_[cl]flags.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      b1245529
    • Richard Levitte's avatar
    • Richard Levitte's avatar
      Add base template processing. · 7d46b942
      Richard Levitte authored
      
      
      Base templates are templates that are used to inherit from.  They can
      loosely be compared with parent class inheritance in object orientation.
      They can be used for the same purpose as the variables with multi-field
      strings are used in old-style string configurations.
      
      Base templates are declared with the base_templates configuration
      attribute, like so:
      
      	"example_target" => {
      		base_templates => [ "x86_asm", ... ]
      		...
      	}
      
      Note: The value of base_templates MUST be an array reference (an array
      enclosed in square brackets).
      
      Any configuration target can be used as a base template by another.  It
      is also possible to have a target that's a pure template and not meant to
      be used directly as a configuration target.  Such a target is marked with
      the template configuration attribute, like so:
      
      	"example_template" => {
      		template => 1,
      		cc => "mycc",
      		...
      	},
      
      As part of this commit, all variables with multi-field strings have been
      translated to pure templates.  The variables currently remain since we
      can't expect people to shift to hash table configurations immediately.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      7d46b942
    • Richard Levitte's avatar
      Add template reference processing. · 09816a2e
      Richard Levitte authored
      
      
      Template references are words with double brackets, and refer to the
      same field in the target pointed at the the double bracketed word.
      
      For example, if a target's configuration has the following entry:
      
          'cflags' => '-DFOO {{x86_debug}}'
      
      ... then {{x86_debug}} will be replaced with the 'cflags' value from
      target 'x86_debug'.
      
      Note: template references are resolved recursively, and circular
      references are not allowed
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      09816a2e
    • Richard Levitte's avatar
      Rewrite Configure to handle the target values as hash tables. · aaf878cc
      Richard Levitte authored
      
      
      The reasoning is that configuration strings are hard to read and error
      prone, and that a better way would be for them to be key => value hashes.
      
      Configure is made to be able to handle target configuration values as a
      string as well as a hash.  It also does the best it can to combine a
      "debug-foo" target with a "foo" target, given that they are similar
      except for the cflags and lflags values.  The latter are spliced into
      options that are common for "debug-foo" and "foo", options that exist
      only with "debug-foo" and options that exist only with "foo", and make
      them into combinable attributes that holds common cflags, extra cflags
      for debuggin and extra cflags for non-debugging configurations.
      
      The next step is to make it possible to have template configurations.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      aaf878cc
    • Dr. Stephen Henson's avatar
      Make X509_ATTRIBUTE opaque. · 9b0a4531
      Dr. Stephen Henson authored
      
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      9b0a4531
  3. 15 Mar, 2015 4 commits
  4. 14 Mar, 2015 2 commits
  5. 13 Mar, 2015 2 commits
  6. 12 Mar, 2015 14 commits
  7. 11 Mar, 2015 4 commits
  8. 10 Mar, 2015 1 commit