- 15 May, 2021 16 commits
-
-
Ben Avison authored
Earlier versions couldn't cope with RES_OBJ being set to an empty string.
-
Timothy E Baldwin authored
This allows makefiles to refer to the parent directory in an OS-neutral way.
-
Ben Avison authored
`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
-
Ben Avison authored
-
Ben Avison authored
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).
-
Ben Avison authored
This brings it into line with AAsmModule and CModule shared makefiles
-
Ben Avison authored
There are at least 19 components that use this tool to autogenerate a source file. Needs initial capitalisation on case-sensitive filesystems.
-
Ben Avison authored
-
Ben Avison authored
-
Ben Avison authored
-
Ben Avison authored
Use `${TBOXINC}` instead.
-
Ben Avison authored
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.
-
Ben Avison authored
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.
-
Ben Avison authored
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.
-
Ben Avison authored
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.
-
Ben Avison authored
-
- 19 Apr, 2021 5 commits
-
-
ROOL authored
For iMx6, remove DDEUtils to match the other ROMs (it's in the HardDisc4 image). Version 7.57. Tagged as 'BuildSys-7_57'
-
ROOL authored
-
ROOL authored
-
Robert Sprowson authored
Requires Env-1_46
-
ROOL authored
-
- 24 Feb, 2021 2 commits
- 21 Dec, 2020 1 commit
-
-
ROOL authored
Version 7.55. Tagged as 'BuildSys-7_55'
-
- 23 Nov, 2020 1 commit
-
-
Julie Stamp authored
Detail: ModuleDB updated to make Obey and Shell as 'C' for ROM builds Version 7.54. Tagged as 'BuildSys-7_54'
-
- 07 Nov, 2020 1 commit
-
-
Robert Sprowson authored
Help2-3_27 now uses the CApp shared makefile. Version 7.53. Tagged as 'BuildSys-7_53'
-
- 28 Oct, 2020 1 commit
-
-
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'
-
- 24 Oct, 2020 1 commit
-
-
ROOL authored
To CTools, for Installer, fixes build as for BuildSys-7_48. Version 7.51. Tagged as 'BuildSys-7_51'
-
- 10 Sep, 2020 3 commits
-
-
Robert Sprowson authored
Edit-1_75's makefile invents trailing application name, remove it here. Version 7.50. Not tagged
-
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 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`, `RES_FILES` and `RESAPP_FILES`. Requires RISC_OSLib-6_08.
-
- 20 Jul, 2020 2 commits
-
-
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 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` rule.
-
- 14 Jul, 2020 1 commit
-
-
Robert Sprowson authored
For Installer. Version 7.48. Tagged as 'BuildSys-7_48'
-
- 27 Jun, 2020 4 commits
-
-
Ben Avison authored
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
-
Ben Avison authored
GNU make doesn't need this extra hint. Version 7.47. Tagged as 'BuildSys-7_47'
-
Ben Avison authored
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.
-
Ben Avison authored
-
- 06 Jun, 2020 2 commits
-
-
Robert Sprowson authored
Version 7.46. Tagged as 'BuildSys-7_46'
-
Timothy E Baldwin authored
Version 7.45. Not tagged
-