[bind10-dev] Why move functionality out of .py.in files

Jelte Jansen jelte at isc.org
Mon May 31 13:52:35 UTC 2010

Hash: SHA1


see ticket #212; http://bind10.isc.org/ticket/212

(I write this message because the subject is more general than this
specific ticket, and because it warrants discussion)

The decision to move as much functionality as possible out of .py.in
files was made at one of the f2f meetings (though I can't seem to find
minutes regarding this specific issue).

It was decided as part of a compromise for having 'generated' files in
the first place, which we need so we can use configure-time options
similar to config.h in cpp, and not have to screw around with
shellscripts calling python scripts for every python-based program in
the system.

In principle this meant calling configure every time you change something.

Moving everything but the most basic stuff (basic meaning mainly option
parsing and the Calling of the Main) outside of the generated .py file
would limit this problem, but of course there are other ways we could
handle this.

Since then, someone came up with the sed trick that results in make
being enough to update the .py scripts. But somehow this still doesn't
feel right to me.

I think we have 3 options here

1. Drop the decision we made back then and declare the sed-way as
allright. Close this ticket, and move back the stuff we did do the
moving out for (at least cfgmgr, I actually don't think there were any

2. Stand by the decision, even with either sed or basic configure
output, as originally planned.

3. Come up with a better way to do the handling of configure-time
variables. One way would be to put these as class constants in a
subclass of the specific module/program. These could be per
module/program or (imho preferably), as one big one for the whole system
(like config.h). Yes this would still be generated then, but it would
only contain constants, and only those set by configure. We would also
not need the sed scripting anymore, since the only time these should
change would be when configure is rerun anyway.

I don't think that last one is really that much work right now, but of
course I'm probably missing a lot of details right now :)


Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the bind10-dev mailing list