- wip "unencapsulated" module. This just means that the module is
loaded into the global scope. You could then write functions like
`vcs_tag` in this global module to be used by all meson files. This
might be removed.
- remove export() function and instead use a lua-like return to export
from the module.
- track language mode in function definitions. Necessary for functions
to use internal-only functions.
- use assigned function name in error messages
- fix embedded source reopening in error messages
- reduce number of node types that get marked as dead code
- create true/false bools on workspace initialization with known ids.
Future code should use these rather than making new boolean objects to
save memory.
- add a new test script-module
python_installation is an external_program with a couple of extra
methods related to the Python installation. Right now, we only add the
type.
Signed-off-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Seedo Paul <seedoeldhopaul@gmail.com>
This will be required for find_program('meson') to return an external
program with the command ['muon', 'meson']. It also allows muon to
return ['muon', 'samu'] as the result for find_program('ninja'), which
is kind of neat.
The invocation:
meson setup -Dlibdir=/usr/lib64 -Dprefix=/usr build
sets libdir to `lib64` because meson detects that it is an absolute path
that is a subdir of prefix. This commit adds the same functionality to
muon.
Currently all compat.h does is define the appropriate POSIX macro unless
you are on windows, as well as conditionally enabling
__attribute__(format...).
Previously, each time a literal was evaluated, a new object was created.
This meant that if you had code like:
foreach x : list
if x == 'hello'
do_something
endif
endforeach
In each loop, when the condition was evaluated, a new string containing
'hello' was allocated. With many loops or lots of literals inside
loops, this can become a source of wasteful memory use.
The implemented solution is to create these objects once during the
parse step, and then reuse them inside the interpreter. Currently only
strings, bools, and numbers get this treatment, but it should be
possible to handle arrays/dicts composed purely of literals as well,
although that would start to get into constant folding.