Python2 is end-of-life [1] since the 1st of January 2020.
Some distributions (most notably: Debian and its derivatives) will stop
providing a `python` executable in order to encourage users to specify
the interpreter language of local scripts explicitly. Users of such
environments will be forced to work around this in one of these ways:
* create a virtual environment or
* manipulate the shebangs of the scripts or
* install the python2 package (as long as it is provided by distributions)
All currently maintained distribution releases provide python3.
In the near future distributions will need to remove python2, since it
is not maintained anymore.
PEP-394 [2] recommends to reference a specific python version
(python2 or python3), if the script is not expected to run in a virtual
environment.
Closes: #1265
[1] https://www.python.org/dev/peps/pep-0373/#update-april-2014
[2] https://www.python.org/dev/peps/pep-0394/#for-python-script-publishers
Amended-by: Karl Palsson <karlp@tweak.net.au>
* moved lpc43xx scripts to explicitly call python2, they have not been
ported, and are effectively unmaintained, but switching them to
python3 unconditionally would be unhelpful.
The nvic_ functions all had a broken link to an f1 list of irqs. Change
the header generator to generate a fixed name, and link to them.
Because of their scoping, this ok, they find the correct family's irq
definitions.
... since Clang doesn't infer the function type on '#pragma weak x = y'-style
declarations, and instead leaves it as "<overloaded function type>", thus
leading to a type conflict when assigning the ISRs to the interrupt vector.
This has no impact on normal use, but it makes it more compatible, nd
that's always a good thing.
Before (vector_nvic.c generated)
...
#pragma weak usart1_isr = blocking_handler
...
After:
...
void usart1_isr(void) __attribute__((weak, alias("blocking_handler")));
...
These prototypes affect functions defined by application code. Only
the implementations in libopencm3 are supposed to be weak; the
functions in application code should definitely not be. Otherwise,
you'll end up with two weak symbols being linked together, and
it's luck as to which one the linker picks.
This converts all the YAML files to JSON files, as json parsing is built
into python instead of being a separate library requiring installation.
YAML is a superset of JSON, but putting comments in is not quite as obvious
as it is in yaml.
The following glue was used to convert yaml to json:
python -c 'import sys, yaml, json; json.dump(yaml.load(sys.stdin), sys.stdout, indent=4)' < $1 > $2
Clearly I haven't tested this on every single platform, and this
doesn't address the large blobs of yaml in the lpc4300 scripts directory,
only the cortex NVIC generation process.
I've tested a few IRQ driven example apps, and I've checked the generated
output of some known cases like the LM3s that has explicit gaps, and they are
all generated correctly.
Added --terse and --mailback options to the make stylecheck target. It
also does continue even if it enounters a possible error.
We decided on two exceptions from the linux kernel coding standard:
- Empty wait while loops may end with ; on the same line.
- All blocks after while, if, for have to be in brackets even if they
only contain one statement. Otherwise it is easy to introduce an
error.
Checkpatch needs to be adapted to reflect those changes.
as header file generation is not directly controlled by make (which, by
the way, makes the generatedheaders target phony), the script has to
take care of not needlessly generating files itself lest to have make
rebuild everything everytime
now tries to mkdir its way to the output files
this wouldn't be a problem currently if it wasn't for the efm32 data
lingering in the wrong branch, but otoh it's just on the safe side in
case we meet architectures that don't need other specializations at all.
Lars Kruse
Karl Palsson
keepkeyjon
Anatol Pomozov
Jim Paris
Karl Palsson
Karl Palsson
Piotr Esden-Tempski
chrysn