While this component is stored in pre-compiled form, we need the header
filenames to be converted to postfix-extension form during the export phase
so that compilers and other code analysis tools will find them. Because this
is a somewhat unusual component, this is achieved with a custom makefile for
cross-compilation use. Support is also included for converting the object
files to ELF format when exporting, if ${TOOLCHAIN}
is GNU
.
Enable GitLab CI (native Makefile
given partial GNU make compatibility to
facilite some of the CI jobs, and as a side-effect will enable correct syntax
colouring in GitLab).
!Tag(OSLib-6_90-2)
ROOL (948af40a) at 22 Oct 10:25
Support cross-compilation
I still strongly disagree with all your assertions above for reasons discussed at length offline, but in order to unblock this MR, I'm backing this out, under protest.
We shouldn't be modifying the upstream OSLib merely to satisfy a false positive warning from a tool being run of our own choosing.
There's no value for x which is an expression with sideeffects that, after expansion, results in valid C code (eg. NOT_USED(fred+5)
=> fred+5 = fred+5
). Just disable the check.
While this component is stored in pre-compiled form, we need the header
filenames to be converted to postfix-extension form during the export phase
so that compilers and other code analysis tools will find them. Because this
is a somewhat unusual component, this is achieved with a custom makefile for
cross-compilation use. Support is also included for converting the object
files to ELF format when exporting, if ${TOOLCHAIN}
is GNU
.
Enable GitLab CI (native Makefile
given partial GNU make compatibility to
facilite some of the CI jobs, and as a side-effect will enable correct syntax
colouring in GitLab).
!Tag(OSLib-6_90-2)