Commit Graph

9 Commits

Author SHA1 Message Date
wm4 f8cc184134 TOOLS: change license of some scripts involved in build to LGPL
wscript calls them directly, and thus are probably part of the build
system. They seem to be fully covered by relicensing agreements.
2017-06-24 10:08:33 +02:00
wm4 0b9f1e0323 TOOLS/file2string.py: fix standalone invocation 2017-01-05 16:45:26 +01:00
Stefano Pigozzi 737e3b1758 build: use matroska.py & file2string.py as python modules 2017-01-05 11:25:18 +01:00
wm4 ff9f5e06ff Revert "Port several python scripts to Perl"
This reverts commit fae7307931.

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 matroska.py/file2string.py directly by
importing them as modules, instead of calling them via "python". But for
now this is simpler.
2016-12-17 15:43:15 +01:00
Kovensky fae7307931 Port several python scripts to Perl
file2string.pl and vdpau_functions.pl are direct ports.
matroska.py was reimplemented as the Parse::Matroska module in CPAN,
and matroska.pl was made a client of Parse::Matroska.
A copy of Parse::Matroska is included in TOOLS/lib, and matroska.pl
looks there first when trying to load the module.

osxbundle.py 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.
2012-11-08 00:28:59 +01:00
wm4 6fb0e6bf1c build: use "python" instead of "python3" as interpreter name
This works regardless whether "python" starts a Python 2 or Python 3
interpreter.
2012-09-29 16:22:01 +02:00
wm4 0ee09dcdbe build: make Python scripts compatible with Python 2.x
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.
2012-09-29 15:53:54 +02:00
wm4 1ee740cceb TOOLS/fil2string.py: fix for use with binary files
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.
2012-07-28 23:36:08 +02:00
Uoti Urpala 2ba8b91a97 build, codec-cfg.c: simplify builtin codecs.conf handling
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/file2string.py.

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.
2012-07-16 21:08:42 +03:00