GitLab

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.

Use `${TBOXINC}` instead.

Use `${TCPIPINC}` instead. Although there is only a single directory
on TCPIPLibs$Path, all ported BSD sockets code assumes their headers are
already directly on the include path.

Typically useful for libraries where you have both types of target, and you
want the application build to contain function names (for meaningful
backtraces) but the module build not to (to save ROM space). This is
achieved as follows:

* CAPPFLAGS and CMODFLAGS contain additional flags to be passed to application
  and module builds, respectively

* C_FNAMES is initialised to a compiler-agnostic build switch to enable
  function names in the binary

Therefore a master makefile will often use the line
CAPPFLAGS = ${C_FNAMES}
although CAPPFLAGS and CMODFLAGS are not limited to this usage.

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.