Boost logo

Boost-Build :

Subject: [Boost-build] Extension style
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-07-20 12:04:11


I've managed to implement first-ever Boost.Build extension in Python,
which exposed some design inconsistency. Here's a relevant bit:

        import b2.build.generators as generators

        generators.register_standard("verbatim.inline-file",
                                     ["VERBATIM"], ["CPP"])

        from b2.manager import get_manager

        get_manager().engine().register_action("verbatim.inline-file",
        """
        ./inline_file.py $(<) $(>)
        """)

As you see, 'generators.register_standard' directly registers generators
in some global table. However, for registering action we explicitly grab
some global data. I have few questions:

1. The straight-forward design is where each module has a set of global
variables that keep its state. For example, the 'generators' module
has a list of generators. An alternative design is having a top-level
"manager" object, which keeps other objects that keep the build system
state -- like list of features, list of generators and so on. Then,
most methods will be passed thos individual objects, or the manager.
The advantage of this design is that in theory, one can load and build
several independent projects -- which is good for IDE integration, for
example. However, coding will become much more inconvenient.

Any comments on what we should prefer? Also, maybe Python allows to
create several instance of the interpreter, in which an IDE would
do just that?

2. Does that 'get_manager().engine()' thing look horrible, or very horrible?

3. Suppose we use 'module.do_whatever' style everywhere. Are there any
tricks to easily update this to 'manager object' style?

Thanks,

--
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build: http://boost.org/boost-build2

Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk