I'll be using this later, but it seems useful to allow dependencies to
that have special handlers to declare that they depend on other
dependencies. This should allow us to stop treating threads special
internally and just make it a normal dependency.
If gtest is patched to have a pkg-config file, that will report the
version, so force the 'system' method to be used when we are exercising
that an unknown version doesn't satisfy any version constraint.
`-Dtest_harmless_but_useless_link_arg` won't actually do anything
without anything to preprocess, but least it is valid for GCC and MSVC,
and won't be caused by anything else.
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.
Currently if a dependency is added to declare_dependency, and the top
dependency doesn't have an attribute that the subdependency does, it
wont be propagated by subdependency.
- Added missing universal options.
- Split options in `directories` and `core` groups.
- Sorted alphabetically some of the groups.
- Removed `cross-file` from options, since it's not an option.
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.
Since sanity check now includes CFLAGS, the test fails earlier.
But if the compiler is ICC, it will only fail during the build proper as
before, since that's where where the flag making `-std=unknown` an error
not warning is used.
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.