This returns a list out of th keys of a dict. In both cases of use
remaining though it's used for checking membership, checking for list
membership, lists are O(n) lookup, while dicts are O(1), so removing
the abstraction reduces typing and improves performance.
Currently the builtins are stored as lists, then there are a mess of
functions which take said lists, check what the type of the first
thing is, and then extract data from various points in the list based
on that.
This is stupid. This is what structs/classes are for.
If we change a symbol size (e.g. array) in a .c file that is a part of
.so, executables that use it are not re-linked resulting in a runtime
error:
"Symbol xyz has different size in shared object, consider re-linking"
Adding symbol sizes to .symbol files fixes this issue.
Sometimes it is convenient to run an arbitrary command (e.g. 'git diff')
on all subprojects.
Add a 'meson subprojects foreach' command to take care of that.
For this command the common argument 'subprojects' does not make sense,
so only add '--sourcedir' and cover the case of a missing
options.subprojects in run().
Currently InternalDependency.get_partial_dependency shadows the the
input variables names, and then passes those new copies to the final
object returned. It also passes them to the arguments of of
get_partial_dependency for each subdependency, which is wrong. The
code is supposed to proxy the original argumetn values to that instead
of the shadowing values.
To avoid that this patch renames the new values.
If POTFILES.in exists, then it will have come from autotools, in which
case it is explicitly the file passed to xgettext -f, and the POTFILES
file itself is generated by autotools as a proxy file which eventually
gets inlined into the final Makefile as a variable "POTFILES = ......"
In this case, attempting to use POTFILES as the input file will simply
result in syntax errors and the inability to find files with a literal
trailing " \" in the name. Usually POTFILES will not exist at all, and
we would fallback on POTFILES.in, but if the source tree happens to be
dirty, this would result in errors. Since it's never going to be right
to use it, we can just do the right thing from the start and carry on.
On Windows, program on a different drive than srcdir won't have
an expressible relative path; cmd_path will be absolute instead and
shouldn't get added into build_def_files.
Previously cross, but not native, external args were used. Then in
d451a4bd97 the cross special cases were
removed, so external args are never used.
This commit switches that so they are always used. Sanity checking works
just the same as compiler checks like has header / has library.
I recall that @jpakkane never wanted this, but @nirbheek did, but then
@nirbheek changed his mind.
I am fine either way except for the cross inconsistency that exists
today: There is no `c_preproc_args` or similar one can put in the cross
file, so no way to replicate the effect of CPPFLAGS during cross
compilation.
It was a mistake in retrospect to not make this deprecated in the
first place, so let's do that. When cross files were new we needed
this as a way to specify a llvm-config binary, since it could be
passed via PATH overrides.
This can be useful to test a local ninja version (for example while developing
changes to ninja or samurai) without modifying the PATH.
The ninja binary that is detected is then hardcoded in the build.ninja
rules for scan-build and clean, so that it is always used until reconfiguration.
commit b02b2d6d0d462310b313588ca7705d391e830eeb
Author: Michael Hirsch, Ph.D <scivision@users.noreply.github.com>
Date: Sun Mar 10 03:51:09 2019 -0400
cleanup
commit 3311ff5fb12577c78671bf2ff2787d28b86ba5fa
Author: Michael Hirsch, Ph.D <scivision@users.noreply.github.com>
Date: Sun Mar 10 03:50:30 2019 -0400
more robust
commit 8030dcb76698b148ee47ecded1f33b6d3821cca2
Author: Michael Hirsch, Ph.D <scivision@users.noreply.github.com>
Date: Sun Mar 10 03:30:05 2019 -0400
inwork compiles OK but needs smod filenames