This reverts commit 94959cb84f.
make_license.py was actually refactored in main, and this is introducing
a minor conflict. I will leave make_license as it is in 4.3, and focus
on the cleanups in main itself.
- Avoid manipulating a dictionary arguments, use return values &
iterators to return results.
- Move logic out of the file reading context once the file was read
(reducing right-shift).
- Move intermediate license data from a dictionary to a named-tuple
for better clarity & type safety.
- Remove use of `dataclass` as a container for constants,
as it quite clear to define the constants directly in the
global namespace.
- Group imports at the beginning of the file (no need to quiet pylint).
- Add headings for code sections.
- Use double quotes.
- Use the term "dir" instead of both dir/folder.
- Note the limitations parsing CMake files directly,
with a possible alternative.
There are two "SPIRV TOOLS" IGC_SPIRV_TOOLS & SHADERC_SPIRV_TOOLS, in:
build_files/build_environment/cmake/versions.cmake
Show both in the license.md file.
Also remove use of defaultdict to make it clear where dictionary
values are created.
Clear trailing space as this has as space at the line end
has a special meaning in markdown.
Write a new line at the end of the file
since some development tools add this or note when it's missing,
it's simplest just to add it.
This generates a `license.md` file with all the relevant information about
the different libraries and their respecive licenses.
This should replace: THIRD-PARTY-LICENSES.txt
Important files:
* `make_license.py` (main script called by `make license`.
* `licenses.json` (file to add the definition of new licenses).
* `licenses/*/*.txt` (individual license files.
The `license.md` groups the libraries per license, list their
corresponding copyright information and include the complete license.
Code includes contributions from:
* Campbell Barton (multi-line parser for versions.cmake).
* Thomas Dinges (Windows support for `make license`).
Part of: !129018
The updated autopep8 was ignoring the "exclude" values because
they started with a "./" instead of a "/".
The documentation I found doesn't go into details, even if this is a
regression in autopep8, update the configuration as it causes
"make format" to format files that aren't meant to be modified.
This renames the mode identifiers to be consistent with e.g. the context mode identifiers and other names used for the new Grease Pencil.
For `object.mode`:
* `PAINT_GPENCIL` -> `PAINT_GREASE_PENCIL`
* `SCULPT_GPENCIL` -> `SCULPT_GREASE_PENCIL`
* `VERTEX_GPENCIL` -> `VERTEX_GREASE_PENCIL`
* `WEIGHT_GPENCIL` -> `WEIGHT_GREASE_PENCIL`
For the internal `ob->mode` flag:
* `OB_MODE_PAINT_GPENCIL_LEGACY` -> `OB_MODE_PAINT_GREASE_PENCIL`
* `OB_MODE_SCULPT_GPENCIL_LEGACY` -> `OB_MODE_SCULPT_GREASE_PENCIL`
* `OB_MODE_VERTEX_GPENCIL_LEGACY` -> `OB_MODE_VERTEX_GREASE_PENCIL`
* `OB_MODE_WEIGHT_GPENCIL_LEGACY` -> `OB_MODE_WEIGHT_GREASE_PENCIL`
Resolves#127374.
Pull Request: https://projects.blender.org/blender/blender/pulls/128604
BaseException was used as a catch-all in situations where it
didn't make sense and where "Exception" is more appropriate
based on Python's documentation & error checking tools,
`pylint` warns `broad-exception-caught` for e.g.
BaseException includes SystemExit, KeyboardInterrupt & GeneratorExit,
so unless the intention is to catch calls to `sys.exit(..)`,
breaking a out of a loop using Ctrl-C or generator-exit,
then it shouldn't be used.
Even then, it's preferable to catch those exceptions explicitly.
