Found via `codespell -q 3 -S "*.pdf,*.po,./.git,*.tosc,./waf,./share/patchfiles,./libs,./msvc_extra_headers,./share/web_surfaces,*.patch" -L acount,addin,ane,ba,buss,busses,caf,capela,devine,disconnectin,discreet,doubleclick,envolution,filetest,fo,ghandi,homs,hsi,layed,maschine,mis,nd,ontop,pass-thru,removeable,retrn,ro,scrollin,sectionin,seh,siz,sord,sur,te,trough,ue,wth`
Rename the worker functions to make it clear that their name in this
case isn't magic. These functions "are not" the waf commands. It is the
custom build context class definitions that define the i18n commands ...
which will invoke these top level worker functions which in turn invoke
the others recursively.
The bare printing of the build environment in the top level i18n command
seems to be old debug code that safely can be removed.
Try to make it a bit more clear what is going on with class and def for
i18n commands.
It was confusing that we first defined i18n classes in the beginning of
the wscript file, and then replaced them with "plain" functions with the
same name at the end. pyflakes also didn't like it.
It seemed magic. The i18n functionality easily broke if trying to touch
that. It deserves an explanation to make it maintainable ... and some
cleanup.
Simple functions in the top level wscript file are generally exposed as
custom waf commands. The command will have the same name as the function
and will get a plain Context. But that simple method doesn't work for
these i18n commands. They have to be declared in a different way with a
custom BuildContext, as seen and described in the comment.
The name of the BuildContext classes doesn't matter, so we change the
name to avoid the name collision and to give a hint how they actually
just are contexts for the commands - they are not the command itself. We
also place the classes next to the corresponding functions so it is more
obvious that they are related.
This likely won't make much difference on modern systems,
since it requires a kernel based I/O scheduler. which is
disabled (set to "none" for NVMe and SSDs).
Previously, the option was called "--vst3", yet disabled building
support for VST3 plugins (as described in the help string).
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
This reverts commit 615326be9b because it
breaks windows builds.
```
File "/home/ardour/ardour-w64/wscript", line 1462, in configure
set_compiler_flags (conf, Options.options)
File "/home/ardour/ardour-w64/wscript", line 522, in set_compiler_flags
if re.search ('x86_64-w64', conf.env['CC']) is not None:
File "/usr/lib/python2.7/re.py", line 146, in search
return _compile(pattern, flags).search(string)
TypeError: expected string or buffer
```
CC is already set to a string. (And if it ever should be None, we want
to handle that explicitly.)
(And #autowaf.display_msg handle Booleans just fine.)
The sub_config_and_use function recursed, but it also invoked
autowaf.set_local_lib , which however didn't do anything useful. The
HAVE_ defines are not used anywhere, and the AUTOWAF_LOCAL defines are
only used in autowaf.use_lib, which however isn't used anywhere.
Dropping these defines simplify the build environment and makes the
compiler command line half as long and thus makes debugging much more
manageable.
Put it in the "children" list instead of recursing explicitly.
The only difference is that the (empty) options function in
libs/clearlooks-newer/wscript now will be invoked - before it wasn't.
