garyo edited this page Dec 13, 2014 · 1 revision

Different classes of users have different needs from a toolchain. This is originally from an email on the scons dev list by Michael Haubenwallner, with some additions by Gary Oberbrunner.

  • The upstream package source maintainer

    • Specify which language-tools are to be initialized: C89, C99, C++, C++11, JavaC, ...
      • or let SCons auto-detect used languages along the list of source-files
    • Avoid the need to take care of platform- and tool-details:
      • Let the language-tool delegate to (or know about): cl.exe/gcc/xlc/hp-cc/...
      • Make additional resource-tools a no-op on platforms not using them
    • Specify package-default (used during development) language-/tool-options
      • warnings (as errors), debugging, optimization, ...
      • the language tool implementation filters unsupported flags
    • Don't care about a library to be static or shared - just define a Library:
      • fex, AIX traditionally used just one file target for both the static and the shared library (yes, shared objects can be linked statically).
    • (maybe more)
  • The downstream (distro) package build/integration maintainer

    • Define the language-tool implementation to use: cl.exe/gcc/xlc/hp-cc/...
    • Define the actual tool-executable to use (PATH, ...)
    • Set the final language-/tool-options:
      • warnings (as errors), debugging, optimization, additional QA flags
      • override the package-default values
    • Define to build the Library as static and/or shared.
    • Define the search path for package dependencies.
    • (maybe more)
  • The downstream (distro) package build/integration maintainer for SCons:

    • Define default language-tool implementation to use: cl.exe/gcc/xlc/hp-cc/...
      • To be used by upstream package source maintainer
    • Define the default tool-executable to use (PATH, ...)
    • Define the default search path for package dependencies.
    • (maybe more)
  • Commercial software developers (in-house)

    • Define exactly which language/tool implementation to use, including version (optionally)
      • Possibly overridable by individual developers or external config files
    • Give good error messages when tools are missing or misconfigured For each design decision, IMHO it is important to think of /who/:
  • defines the defaults,

  • overrides the defaults,

  • prepends/appends to the defaults.

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.