path: root/TOOLS/
Commit message (Collapse)AuthorAgeFilesLines
* TOOLS: change license of some scripts involved in build to LGPLwm42017-06-241-0/+17
| | | | | wscript calls them directly, and thus are probably part of the build system. They seem to be fully covered by relicensing agreements.
* TOOLS/ fix standalone invocationwm42017-01-051-1/+1
* build: use & as python modulesStefano Pigozzi2017-01-051-5/+9
* Revert "Port several python scripts to Perl"wm42016-12-171-0/+27
| | | | | | | | | | | | | | | | | | This reverts commit fae73079310eef9dce9737f2e37ff4b80c8830ee. Before the waf build system was used, we had a configure script written in shell. To drop the build dependency on Python, someone rewrote the Python scripts we had to Perl. Now the shell configure script is gone, and it makes no sense to have a build dependency on both Perl and Python. This isn't just a straight revert. It adds the new Matroska EBML elements to the old Python scripts, adjusts the waf build system, and of course doesn't add anything back needed by the old build system. It would be better if this used directly by importing them as modules, instead of calling them via "python". But for now this is simpler.
* Port several python scripts to PerlKovensky2012-11-081-27/+0
| | | | | | | | | | | | and are direct ports. was reimplemented as the Parse::Matroska module in CPAN, and was made a client of Parse::Matroska. A copy of Parse::Matroska is included in TOOLS/lib, and looks there first when trying to load the module. was not ported since I have no means to verify it. Python is always available on OSX though, so there is no harm in removing the check for it on configure.
* build: use "python" instead of "python3" as interpreter namewm42012-09-291-1/+1
| | | | | This works regardless whether "python" starts a Python 2 or Python 3 interpreter.
* build: make Python scripts compatible with Python 2.xwm42012-09-291-1/+5
| | | | | They were originally written for Python 3.x. Changing them to work on Python 2.x as well is trivial. Tested with Python 2.7.3 and 3.2.3.
* TOOLS/ fix for use with binary fileswm42012-07-281-1/+1
| | | | | | | | | | The script was written to be able to deal with binary files, but it had a bug corrupting some data: e.g. a byte sequence 0x1 0x37 was printed as "\17" (0x1 = escaped as "\1", and 0x37 = kept as literal "7"), which would be interpreted as single character 0xF. Always pad octal literals to length 3, which makes the escape sequences unambiguous.
* build, codec-cfg.c: simplify builtin codecs.conf handlingUoti Urpala2012-07-161-0/+23
The player can read codec mapping (codecs.conf) from an external file or use embedded defaults. Before, the defaults were stored in the player binary in the form of final already-parsed data structures. Simplify things by storing the text of the codecs.conf file instead, and parse that at runtime the same way an external file would be parsed. To create the previous parsed form, the build system first compiled a separate binary named "codec-cfg", which parsed etc/codecs.conf and then wrote the results as a C data structure that could be compiled into the program. The new simple conversion of codecs.conf into a C string is handled by the new script TOOLS/ After removing the codec-cfg binary, HOST_CC is no longer used for anything. Remove the --host-cc configure option and associated logic. Also remove the codec2html and codec-cfg-test functionality. Building those was already broken and nobody cared. There was a broken 3-character-long "fourcc" entry in etc/codecs.conf. This happened to be accepted before but triggered a parse error after the changes. Remove the broken entry and make the parsing functions explicitly test for this error.