1. 15 May, 2021 22 commits
  2. 19 Apr, 2021 5 commits
  3. 24 Feb, 2021 2 commits
  4. 21 Dec, 2020 1 commit
  5. 23 Nov, 2020 1 commit
  6. 07 Nov, 2020 1 commit
  7. 28 Oct, 2020 1 commit
    • Robert Sprowson's avatar
      Fix to module-wrapped LIBS SYMS · b1350268
      Robert Sprowson authored
      Exercising the new library/symbols selector on a more complex case (Help2) showed that the selection never triggered, because where it is placed ${RLIB} is unset.
      Move the test to after ModuleLibs/AppLibs are set, and invert the sense (it should have been ifneq).
      Version 7.52. Tagged as 'BuildSys-7_52'
  8. 24 Oct, 2020 1 commit
    • ROOL's avatar
      Add RMVersion · 887191e2
      ROOL authored
      To CTools, for Installer, fixes build as for BuildSys-7_48.
      Version 7.51. Tagged as 'BuildSys-7_51'
  9. 10 Sep, 2020 3 commits
    • Robert Sprowson's avatar
      Build fix · ca85c288
      Robert Sprowson authored
      Edit-1_75's makefile invents trailing application name, remove it here.
      Version 7.50. Not tagged
    • Ben Avison's avatar
      Define toolchain-agnostic warning suppression flags · a11503f7
      Ben Avison authored
      C_NOWARN_ASSIGNMENT_AS_CONDITION to suppress warnings about assignments within
      condition tests in `if` statements
      C_NOWARN_NON_ANSI_INCLUDES to suppress warnings about use of angle brackets
      for #include headers not defined by ISO/ANSI
      Version 7.50. Tagged as 'BuildSys-7_50'
    • Ben Avison's avatar
      Extend `CApp` to support module-wrapped applications · 02c570ff
      Ben Avison authored
      This involves grafting in the `resources`, `rom` and `rom_link` rules from
      `CModule` (support for `CmdHelp` files is not copied across, because no
      module-wrapped application can provide star commands). Module-wrapped
      applications typically want to support `install INSTTYPE=app` in the same way
      as other applications, to permit a non-wrapped version to be built (for
      example, for debugging purposes).
      Because this feature is typically used with applications that use RISC_OSLib,
      the rules have been made slightly more sophisticated than those in CModule,
      in the sense that if `LIBS` contains `${RLIB}`, it automatically selects the
      larger ROM stubs and symbols files that include the RISC_OSLib library chunk,
      so there is no need to override these from the calling makefile.
      Compared to the `install` phase, where all resource files go into the
      application directory, for ROM builds, only a subset of files go there,
      the remainder being placed under `Resources:$.Resources`, and some of the
      files differ in contents from the `install` versions. The application
      directory resources in the ROM build case are (in a change from previous
      behaviour) all now registered with ResourceFS by the module-wrapped
      application rather than by the Messages module, and they are packaged using
      the `ResGen` tool. This means that you can kill (or unplug) the module and
      teh application will disappear from `Resources:$.Apps`.
      The resource files are categorised using the separate macros `INSTAPP_FILES`,
      Requires RISC_OSLib-6_08.
  10. 20 Jul, 2020 2 commits
    • Ben Avison's avatar
      Change a few modules to `C` type · bccb299b
      Ben Avison authored
      These components have pending merge requests that mean they are likely to
      move to use the `CModule` shared makefile in the near future, which will
      require the use of their `rom_link` rule. However, due to the change to
      `AAsmModule` in the last commit, we can change their type now in anticipation.
      I'm not going further and change all `ASM` components en masse, because not
      all of them will yet have been converted to use `AAsmModule`. This is also
      the reason for not making the change in `srcbuild` itself.
      Version 7.49. Tagged as 'BuildSys-7_49'
    • Ben Avison's avatar
      Enable rom_link target for AAsmModule components · f9c01ed0
      Ben Avison authored
      The ModuleDB classifies modules as being of type either `ASM` or `C`. The
      primary consumer of this information is `srcbuild`. The difference between
      them, as far as `srcbuild` is concerned, is only that in the `install_rom`
      phase, it builds the `rom_link` phony target in `C` components' makefiles,
      instead of the `install_rom` phony target.
      These phony targets differ slightly in requirements: `install_rom` uses
      `INSTDIR` where `rom_link` uses `LINKDIR`, but more significantly, `rom_link`
      is passed parameter `ADDRESS` to state where in the ROM the module resides.
      This addesss is not known at the time the `rom` phony target is made, so `C`
      components only produce a partially-linked binary at that stage, where `ASM`
      components have already produced a complete binary. (The reason for this
      difference is that while hand-written assembly modules use position-
      independent code, the output of the Norcroft compiler normally relies on
      run-time code modification to relocate absolute addresses - something that is
      not possible when running from ROM.)
      There are implementations of the `install_rom` and `rom_link` rules in the
      `AAsmModule` and `CModule` shared makefiles respectively, so `AAsmModule` is
      currently only used for `ASM` components and `CModule` is only used for `C`
      components. However, occasionally we have reason to change a component from
      using `AAsmModule` to `CModule`, usually for reasons unrelated to the use of
      absolute address relocations, because `CModule` is more flexible than
      `AAsmModule` in various other ways.
      This poses a problem for keeping `BuildSys` in step with the component in
      question, because whenever we change the shared makefile type in the
      component's makefile, we have to update the `ModuleDB` in lock step.
      The solution presented here is to ensure that at least one shared makefile
      supports both phony targets, so any component using it no longer cares how it
      is recorded in the `ModuleDB`. Adding `install_rom` to `CModule` was rejected,
      on the grounds that it would be too easy to accidentally build a ROM using it
      where the necessary relocations had been skipped at ROM link time. However,
      there are no drawbacks to adding `rom_link` to AAsmModule, because linking
      an object that has no relocations at any base address will always result in
      an identical binary that is safe to execute.
      Though the module itself requires no relocations, the symbols file
      traditionally output by `CModule` does contain absolute addresses which are
      useful for debugging, so a new link command is executed during `AAsmModule`'s
      `rom_link` rule in order to ensure this is kept up-to-date, even though the
      binary could otherwise have been re-used from the one generated in the `rom`
  11. 14 Jul, 2020 1 commit