GitLab

By contrast with `INSTRES_FILES` in `CModule`, where `Messages` is implicitly
included, `CApp` and `BasicApp` do not do this for `RES_FILES`. The native-
compilation version of `CApp` was doing duplicate installations of `Messages`,
which was at odds with the cross-compiling `CApp` and both versions of
`BasicApp`. If this version of `CApp` is used with a component that doesn't
feature a `Messages` file (such as the in-development `InetRes`) this results
in an error.

The only existing `CApp` client components that define `RES_FILES` are
`Help2` and `EditApp`, and they both explicitly list `Messages`, so this
change should not break either of them.

In the cross-compiling case, a rule is defined targeting `MERGEDMSGS`, which
the phony target `resources_cmdhelp` depends on, but the definition is
conditional on `CUSTOMRES` not being `custom` or `no`.

In a use-case which is believed to be unique to LanManFS, it is required
that the resource files not be registered to ResourceFS via the Messages
module, but by LanManFS itself, both for RAM and ROM builds, but the merging
of `CmdHelp` and `Messages` files is still required. To leverage the
`Messages` merging code in `CModule`, re-enable the `MERGEDMSGS` rule when
`CUSTOMRES=no` (which is arguably the correct setting for LanManFS) but leave
it disabled for `CUSTOMRES=custom` to permit full customisation if required.

* Add cross-compilation `CUtil` makefile fragment and define `SUFFIX_UTILITY`
* Switch to linking with `-util`. This automatically attaches headers and
  footers to the binary, and requires `link` 5.36 (16 Mar 2014 - long enough
  ago that I think that we can assume everyone wil have upgraded)

This allows RISC OS Wimp template files with filetype fec to be referenced
identically whether native or cross-compiling (it expands to an empty string
when used natively).

This was accidentally stripping the `,ffa` from the filename at the final
copy step.

Norcroft's `-We` option suppresses warnings about casts between function
pointers and non-function objects.

Norcroft's `-Wn` option suppresses warnings about implicit narrowing casts.

GCC doesn't have equivalents to these warnings, so they expand to an empty
string if that's the selected compiler.

The following are changed to type `C`. This will permit these components to
switch to using the `CModule` shared makefile in upcoming changes.

* ADFSFiler (and SCSIFiler and SDFSFiler, built from the same sources)
* SpriteExtend
* TaskManager

The following are changed to type `EXP`. These components don't define
`resources` or any subsequent phony targets. `amu` wil fail silently when you
try to make these, but GNU `make` considers it an error.

* DDTLib
* DebugLib
* DeskLib
* ModMallocLib
* PDebug
* RemoteDebug
* Trace
* Wild
* tboxlib

* Define `DEFMOD` for cross-compilation use.
* Define `SETTYPE` for cross-compilation use (this acts as a no-op; when
  cross-compiling, filetypes are indicated using ,xx suffixes instead).
* Define `RUN` tool for both native and cross-compilation. This is already
  used in various components, but wasn't defined anywhere. It is particularly
  useful during cross-compilation for launching build tools that were built
  locally to a component, since on systems other than RISC OS, the current
  directory is typically not on the run path.

* Add `standalone` target for CApp makefile clients.

  This is analogous to `standalone` for CModule clients, and is implemented
  as an alias for the `all` target. This is useful because cppcheck CI jobs
  need a consistent way to ensure that all local autogenerated source and
  header files have been created, so that cppcheck can fully analyse the
  source code.

* Enable install target for cross-compiling CLibrary components.

  `install` was missing from the list of targets that need to be re-run from
  within the `objs` subdirectory.

* Define cross-platform name for ConfigLib header include path.
* Define cross-platform name for tboxlibint header include path.
* Undefine `${TCPIPINC}` when building with GCC (as with the standard C
  headers, the headers in TCPIPLibs conflict with those on the default
  include path when compiling with GCC. Our TCPIPLibs headers appear to be
  incompatible with GCC, so resolve the conflict by removing TCPIPLibs from
  the path).

* Add symbolic names for ImageLb libraries.

Cppcheck 1.84 or later permits warning suppressions to be specified on a
per-symbol basis, provided the suppressions are specified in an XML file.

We wish to make use of this to reduce the number of inline suppression
markers in source files. However, it is difficult for a CI job script to know
how to analyse a CMHG file, because the filename and build options vary from
component to component. It is much easier instead to automatically emit an
consistently-named XML file during the standard CMHG rule in the shared
makefiles, especially since the cppcheck CI job needs to run CMHG anyway in
order to auto-generate a C header file from the CMHG file. So this is what
we do here. The only environment for which this is enabled is Norcroft-based
cross-compilation, but that's the only one we need.

Another precedent for this sort of build side-effect are the symbol listing
files that are generated during ROM link - although in that case they are
primarily to assist debugging the resultant ROM images.

Version 7.65. Tagged as 'BuildSys-7_65'

The CEXPDIR and EXPDIR names are the wild so hang around as aliases until those components are visited.
Purely for symmetry add the same to AAsmModule.

Version 7.64. Tagged as 'BuildSys-7_64'

AppLibs/ModuleLibs:
DebugLib requires remotedb to link, and both are present, but remotedb requires InetLib and SockLib. Currently client makefiles must specify this, but can't do via DBG_LIBS because of the ordering, so end up having to mess around with LIBS in a conditional.
Simplify this by providing the libraries in DEBUGLIBS.

CModule:
Add a new SA_TARGET_RULE variable so that when CUSTOMSA is in use it is still possible to invoke the standalone build without needing to know about the differences between GNU and native makefiles (one uses 'MyModule,ffa' the other 'rm.MyModule').
This will allow the 5 uses of CModule to be simplified in future, the 5 uses of AAsmModule for CUSTOMSA are just to stop a module being output.

The comment in LibIncludes mentions libraries that depend on other libraries may find those path variables useful, but since CLibrary doesn't itself include ModuleLibs or AppLibs, they expand as empty. Add LibIncludes.

Version 7.63. Tagged as 'BuildSys-7_63'

Version 7.62. Tagged as 'BuildSys-7_62'

These make it possible to build softload versions of several extra modules.
Requires Products/Disc!8

Version 7.61. Tagged as 'BuildSys-7_61'

This macro is used to define the root directory for exported C header files.
Previously, when native-compiling, the default setting, if not otherwise
overridden by the master makefile, was `<cexport$dir>.Interface.h`. This is
at odds with the cross-compiling case, which defaults to the equivalent
string, but without the `h` subdirectory, for obvious reasons.

Only one component, DHCP, currently overrides `C_EXP_HDR`, although more will
be joining it in the near future. The macro is used internally within rules
defined by `CModule`, but a few components also use it within rules in their
master makefiles.

We hereby change the default value to omit the `h` subdirectory, and permit
master makefiles to specify an override value which also omits it (in future
it wil be deprecated to include it, and its use will be phased out). There
are two reasons for this:

1) It assists with cross-compilation, since the override can then be
   expressed identically for both native and cross builds.

2) It permits the `.exphdr.h` suffix rule to be re-used when one or more
   headers need to be exported to a subdirectory of `C_EXP_HDR`, so long as
   the headers are present at an equivalent subdirectory in the component
   source tree, and that subdirectory is on `VPATH`. This is because `$<`
   is set up to include the element of `VPATH` that matched the rule - but
   this needs to go before the `.h`, not after it.

To prepare for this MR, the following must all be merged:
* RiscOS/Sources/FileSys/ADFS/ADFS4!2
* RiscOS/Sources/HWSupport/ATA/SATADriver!2
* RiscOS/Sources/HWSupport/SD/SDIODriver!5
* RiscOS/Sources/HWSupport/SPIDriver!1
* RiscOS/Sources/HWSupport/USB/USBDriver!9

Version 7.60. Tagged as 'BuildSys-7_60'

The `BasicApp` fragment is analogous to the `CApp` fragment in that it
supports both single-file executables and application directories. Rules are
included for building any such application directories into ROMs, with
files destined for `Resources:$.Resources` being exported to the Messages
module during the `resources` phase, and those destinated for
`Resources:$.Apps` being built into a position-independent module, so that
when the module is killed or unplugged, those files disappear from ResourceFS.

Because the module is position-independent, the makefile fragment implements
the `install_rom` rule rather than the `rom_link` rule used by `CApp`. This
is consistent with how `srcbuild` already installs ROM components listed in
the ModuleDB as being of type `BAS`.

The other main difference from `CApp` is that there is no compilation or
linking step. Tokenisation, crunching and squishing of the (untokenised)
source files are roughly analogous to the compilation steps, except that
multiple source files are concatenated (if applicable) as the first step.
There is also no debug build variant, and so no `debug` rule.

Crunching is performed (on native builds) using the `BasCrunch` tool, so if
you are converting an existing component which includes its own Command
script to perform tokenisation and crunching, this will no longer be needed.

Cross-"compilation" is fully suported. This uses the new `toffb` tool for
tokenisation (apologies for the wheel-reinvention, but this was developed in
ignorance about Steve Fryatt's `Tokenize` tool; `toffb` also does do a more
faithful job of replicating BASIC's `CRUNCH` options, so is more useful for
ensuring cross-compilation builds remain identical to the native builds).
It also uses Matrix Brandy (V1.22.9 or later) to execute Squish (at least
RiscOS/Tools/Sources/Squish!1).

We pass the new `-nosavepath` option to Squish to ensure that the results are
identical for cross-compile builds compared to native ones. However, Squish
ignores unrecognised command-line options, so this does not introduce a
dependency on a newer Squish tool for native builds.

One subtle enhancement over previous makefiles is that we create dynamic
dependencies between the crunched-and-squished program and its untokenised
source files.

Version 7.59. Tagged as 'BuildSys-7_59'

Missing `$` character before `{LOCALE}` would have caused UK resources to
be selected instead of non-UK ones, if anyone were to be doing an
internationalised cross-compiled build.

This allows RISC OS abstract data files with filetype ffd to be referenced
identically whether native or cross-compiling (it expands to an empty string
when used natively).

This only applies to cross-compilation builds. The `make links` rules don't
know a pre-determined list of subdirectories that need to be converted into
filename extensions. Instead, files that should have no filename extension
are usually simply identified by the absence of a `/` in their specification
in `SOURCES_TO_SYMLINK`. However, this is insufficient to handle some rarer
cases, such as a `Makefile` within a `Test` subdirectory.

To handle this, we introduce explicit support for specifying such files in
`SOURCES_TO_SYMLINK`, using a double slash where there would otherwise be a
filetype subdirectory name, such as `Test//Makefile`. (Conveniently, this is
also valid Posix filename syntax anyway.) The way this is achieved is to
tweak the regular expressions to require the directory and leafnames between
slashes to be at least one character long.

Version 7.58. Tagged as 'BuildSys-7_58'

With GNU `make` unlike with `amu`, it is considered an error to make a target
for which no rule is defined. Therefore we need an explicit no-op `export`
rule in the cross-compiling `CApp` makefile.

`AAsmModule`, `CApp`, `CLibrary` and `CModule` implicitly include various
other shared makefile fragments to permit simpler master makefiles. However,
when cross-compiling, they were only included when invoked from within the
`objs` subdirectory, which in particular meant you couldn't rely on any of
the definitions from `StdTools` when extending the `clean` rule unless you
explicitly included it from the master makefile, thereby defeating the
purpose of the implicit inclusion. Change them so that `StdTools` is included
for all rules.

This tells it to use gcc for preprocessing the CMHG file (if enabled) and
asasm for the backend (which means the object file is an ELF file, required
in order to link with GCC objects).

Occasionally, it is useful to be able to set C++FLAGS from the calling
environment, for example when building a 32-bit x86 target from a 64-bit
x86-64 host. This works fine for CFLAGS and LDFLAGS, but C++FLAGS is not a
valid Posix environment variable name. Import setting from CXXFLAGS instead
when cross-compiling.

When executing the makefile from within the `objs` directory, this now
includes an implicit `-C..` option. This makes it simpler to write agnostic
makefiles. For example,

	${MAKE} -f other${EXT}mk other_target

rather than

ifeq (,${MAKE_VERSION})
	${MAKE} -f other/mk other_target
else
	${MAKE} -f ../other.mk other_target
endif

Earlier versions couldn't cope with RES_OBJ being set to an empty string.

This allows makefiles to refer to the parent directory in an OS-neutral way.

`TOKHELPSRC`, `HELPSRC` and `TOKENS` have the same meaning as in `AAsmModule`.
Because `CModule`, unlike `AAsmModule`, can build a binary from multiple
linked object files, it is also necessary to specify which object file(s)
depend on the autogenerated source file. This is achieved with the new input
variable `TOKHELPDEPENDS`. This defaults to `OBJS` which in turn defaults to
`TARGET`, which should mean that any components converted from `AAsmModule`
will not require any such line to be specified in their master makefile.

Requires RiscOS/Sources/Programmer/Debugger!4

This allows Perl files with filetype 102 to be referenced identically whether
native or cross-compiling (it expands to an empty string when used natively).

This brings it into line with AAsmModule and CModule shared makefiles

There are at least 19 components that use this tool to autogenerate a source
file. Needs initial capitalisation on case-sensitive filesystems.