Google Groups

Re: [waf-users 2139] Re: Configuration environment in custom targets


Thomas Nagy Oct 2, 2009 1:07 PM
Posted in group: waf-users
>> 1. Define a class i18n_context for your command i18n(ctx), and let
>> that class inherit Build.BuildContext
>> There is no example for this, but looking at Scripting.py may help
>>
>> 2. If there is only have one environment, load it directly:
>> import Environment
>> env = Environment.Environment()
>> env.load('build/c4che/default.cache.py')
>> print env
>>
>> You can also have a look at playground/daemon/
>
> OK, I think I can do everything I wanted. However, all this is rather
> suboptimal.
> 1. The context class name for the custom command is fixed.

And what is the problem with having the context class name matching
the method name?
build_context (if provided) -> def build(ctx):

> I'd rather
> have something like this:
>
> (in Utils.py)
> context_dict = {}
> class command_context(object):
>   def __init__(self, name):
>      self.name = name
>   def __call__(self, ctx):
>      context_dict[self.name] = ctx
>
> (in scripts)
> @command_context('i18n')
> class I18nContext(Build.BuildContext):
>   pass
> # command_context('i18n')(I18nContext) # for Python < 2.6
>
> def i18n(ctx):
>   ...
> then when running the command, context_dict would be used to create an
> instance of the required context. Another way would be to use
> decorators for custom commands in the toplevel script:
>
> @context(Build.BuildContext)
> def i18n(ctx):
>   ...

That is not so different from:
i18n_context = Build.BuildContext
def i18n(ctx):
    ...

> I can prepare a patch if you accept one of those approaches. I think
> this would make custom commands easier to use.

Apis are frozen in waf 1.5, except for solving bugs. And the above
does not fall in the "urgent bug" category.

> 2. When I inherit from BuildContext, I need to initialize it
> explicitly with this boilerplate before using it:
>
> env = Environment.Environment(Options.lockfile)
> bld.load_dirs(env[Constants.SRCDIR], env[Constants.BLDDIR])
> bld.load_envs()
>
> Could this initialization be done in the constructor of the build
> context?

No, because the build context is used by the configuration context
wafadmin/Tools/config_c.py

Such changes will be for waf 1.6 (which will be for Python 3.x exclusively)

> I'd really like more orthogonality between built-in and
> custom commands. I think the build_imp() function from Scripting
> should be either a virtual method of the build context, or integrated
> with the constructor.

What do you mean by "virtual method of the build context"?

> 3. Why not inherit and have InstallContext, CleanContext and
> UninstallContext instead of doing this all in the build context? All
> those could have a single overloaded method that determines what is
> done after user code creates task generators. I think this would
> simplify code in Scripting.py a lot.

The classes are defined if not present; try this:

def build(ctx):
        print install_context
        print clean_context
        print uninstall_context

> 4. One final thing (maybe a bit off-topic): Is there any CC-BY-SA
> documentation for Waf? The Waf book cannot be included in Debian or
> contributed to by others because it is CC-BY-NC-ND.

The purpose is to prevent distributions from packaging Waf (or at
least to reduce the benefits from doing so).

Waf is a build script, not an application. Packagers should not
default to the system scripts "just because", but rather use the
application-provided build scripts.

Debian is packaging Waf despite my warnings, and i have already got a
few bug reports such as "Midori does not compile on Debian".

Thomas