GitLab

Occasionally, a library needs to export additional files that don't live in
either an h or hdr directory and (when cross compiling) shouldn't have a
.h suffix added to their exported version. A typical example would be where
the licence conditions of the library require a licence header to be attached
to all copies. To achieve this, CLibrary now uses EXPORTS in a similar manner
to how AAsmModule does, simply as a dependency of export_hdrs, which can
expand to any additional targets you need to define. By default, it overrides
the internal targets EXPORTING_HDRS and EXPORTING_ASMHDRS (derived from
HDRS and ASMHDRS supplied by the master makefile), but you can always include
them in your definition of EXPORTS if desired.

This de-duplicates some of the information from AppLibs and ModuleLibs,
which now include the new Makefile fragment in order to ensure compatibility.
It also means that the definitions can be used for building other library
components, which by definition do not perform a link step, without having
to choose either AppLibs or ModuleLibs when most of either one is unused for
a library build.

For iMx6, remove DDEUtils to match the other ROMs (it's in the HardDisc4 image).

Version 7.57. Tagged as 'BuildSys-7_57'

Requires Env-1_46

Version 7.56. Tagged as 'BuildSys-7_56'

Version 7.55. Tagged as 'BuildSys-7_55'

Detail:
  ModuleDB updated to make Obey and Shell as 'C' for ROM builds

Version 7.54. Tagged as 'BuildSys-7_54'

Help2-3_27 now uses the CApp shared makefile.

Version 7.53. Tagged as 'BuildSys-7_53'

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'

To CTools, for Installer, fixes build as for BuildSys-7_48.

Version 7.51. Tagged as 'BuildSys-7_51'

Edit-1_75's makefile invents trailing application name, remove it here.

Version 7.50. Not tagged

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'

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`,
`RES_FILES` and `RESAPP_FILES`.

Requires RISC_OSLib-6_08.

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'

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`
rule.

For Installer.

Version 7.48. Tagged as 'BuildSys-7_48'

StdTools: new symbol SUFFIX_HEADER: '.h' for GNU make, undefined for amu; useful for generating filenames of generated headers
StdTools: new symbol EXT: filename extension separator character
CModule: ROM_SYMS: now defined conditionally, permitting it to be overridden higher up the master makefile, to match SA_LIBS and ROM_LIBS

Version 7.47. Not tagged

GNU make doesn't need this extra hint.

Version 7.47. Tagged as 'BuildSys-7_47'

Various components use objasm for its general macro abilities in order to
generate intermediate source or header files. To date, this has required
writing of custom rules, which then need separate implementations for
cross-compilation use.

There is no standardisation of destination directory (it may be generating
source or header files in any arbitrary language) so the solution here is to
specify each target using a subdirectory, basename and extension, and leave
CModule to deal with whether or not the extension should be in prefix or
suffix position, depending on the host OS. Only one such autogenerated file
is currently supported per makefile:

```
ASM2TXT = <basename> <optional extension>
ASM2TXT_SUBDIR = <optional subdirectory, each element followed by ${SEP}>
```

The source file passed to objasm is derived from `<basename>`, prefixed by
`s.` or suffixed by `.s` as appropriate.

Version 7.46. Tagged as 'BuildSys-7_46'

Version 7.45. Not tagged

* Put the GENET autosense into !InetSetup
* Export Dialler's header for !Browse now the component is published.
* Chuck MailMan in the bonus bin, for that Econet mail experience.

Version 7.45. Tagged as 'BuildSys-7_45'

Replace redundant AUNMsgs module with WindowScroll, to avoid unplugged
modules being shuffled.

Also remove rogue AcornURI from BCM2835 ROM.

Version 7.44. Tagged as 'BuildSys-7_44'

PPP also turned out to need Dialler exports, so that got released too.
Add PPP to the Disc components, and Dialler for its exports.

Version 7.43. Tagged as 'BuildSys-7_43'

Add FormEd to ModuleDB now it's used in the BonusBin component.

Version 7.42. Not tagged

At time of writing neither works, but they go dormant gracefully.

Version 7.42. Tagged as 'BuildSys-7_42'

Terrible window editor WinEdit is in the bonus bin, so why not FormEd too.

Set the -at address to match reduced HAL size (from Env-1_43).
Remove EnforceSCSI4 predefine from iMx6, there's no such switch in the Kernel, replace it with best guess as might have been: configure SCSI drive 4.

Detail:
  AcornSSL now built from source.
  AcornHTTP TARGET changed.
  Missing headers from FileSwitch added.
Admin:
  Build completed (having started from standard Exports in DDE29a).

Version 7.41. Tagged as 'BuildSys-7_41'

make-cppp-depend => make-cpp-depend

Version 7.40. Not tagged

Version 7.40. Tagged as 'BuildSys-7_40'

Don't try and be clever using Build$Path, just refer to touch directly (since uses of it elsewhere don't have *Run).

Version 7.39. Tagged as 'BuildSys-7_39'

Version 7.38. Tagged as 'BuildSys-7_38'

Those RAM loading modules which pick from VersionNum and insert into their Messages would create a new Messages file with a new date every time they are built. Because the tools to put these in ResourceFS also capture the file's datestamp (via :FLOAD: :FEXEC: in objasm, or via resgen for C modules), you don't create binary identical copies on two successive builds despite the same input source.
Add a ${TOUCH} step to copy the reference time stamp to the generated Messages file.

Requires Library-1_96 or later for Touch.