Wednesday, January 18. 2012
Andrew Bartlett and Amitay Isaacs
- Samba has hardcore portability requirements.
- m4, sh, and other bare-bones tools. autoconf gone mad: 4,000 lines of m4 code.
- Scripting language of the month club: Python, then TCL, then Lua were all put in and pulled out. None of them were loved or portable enough.
- Then Perl went in.
- Became used for all manner of build and testing tasks.
- awk was then used to try and develop an IDL to autogenerate code to spec. It didn’t really work as you’d like, needing tweaking by hand.
- This lead to PIDL, the Perl IDL compiler. It worked far better, with IDL code being used as-is, no tweaking required. Use is now pervasive, generating both server and client code.
- This has been hugely productive and important in allow significant, rapid change.
- Then it caught JavaScript before it was cool. Tride gave many convincingsounding reasons as to why it’s a great idea.
- It was very easy to embed, with minimal dependencies to make it work.
- JS could even make RPC calls.
- But something went wrong. The cool kids were using Python. So they went back to Python. There may have been chloroform and lies to subdue tridge.
- These lies may have revolved around embedded python and debugging.
- Tridge is now a python fanboi. There’s a general love of Python permeating the project.
- IDL generated bindings are everywhere, with bindings into every component: ldb, tdb, and so on. If it’s a useful part of Samba, you can probably access it directly from within Python.
- Things that were being done in C are being migrated to Python; e.g. samba-tool has migrated from a pure C tool to a Python tool with C extensions.
- Many small tasks are now fork()ed from the core Samba processes and run as Pyhon tools - which makes it trivial to debug bad cases by running the tool from the command line with the same parameters.
Some Examples
- The Samba3 migration tools were clunky; in 2 weeks they were (re)-written in Python with C bindings. The business logic was re-written in Python.
- Python is now the core of the build system, via WAF.
- Does ABI checking: checks that all the contracts are consistent, and alerts developers when they aren’t. Maps all the dependencies.
- Testing Samba: both unit testing and environment testing. The latter is the more challenging, because it requires a running server. And there are many, many different options for Samba 4 when running as an AD server. So it ends up creating 7, 8, or more environments for the test suites to run.
- These tests are now run as part of the commit process - continuous integration. 9,000 tests in 1,300 test suites.
|
