This does not convert the build side, or remove any of the checking it
does. We still need that for other callers of custom target. What we'll
do for those is add an internal interface that defaults things, then
we'll be able to have those callers do their own validation, and the
CustomTarget validation machinary can be removed.
Fixes#9096
Hardcoding the name is fragile, and enabling it based on the existence of
/etc/debian_version (as the is_debianlike helper does) will result in
incorrect paths if the Python binary is not provided by Debian.
Using the deb_system distuils scheme instead makes sure we use the
install path from the current interpreter, which Debian could change
between releases, and gives us the correct value on Python installations
that are not provided by Debian (eg. deadsnakes, Github Action Python,
etc.)
Do notice, though, that there is still no guarantee that these are the
correct paths, as they assume all schemes paths have the install prefix
as a base, see #9284.
Signed-off-by: Filipe Laíns <lains@riseup.net>
I ran into one of these from LGTM, and it would be nice if pylint could
warn me as part of my local development process instead of waiting for
the CI to tell me.
This really is more of a struct than a dict, as the types are disjoint
and they are internally handled, (ie, not from user input). This cleans
some things up, in addition I spotted a bug in the ModuleState where the
dict with the version and license is passed to a field that expects just
the version string.
In commit 3c4c7d0429 the qresource
variable stopped being overwritten with a mesonlib.File, which is
reasonable. However, one call site for it which relied on being a built
file did not get renamed when needed.
Make the build target use the built file.
And more accurate too, TBH. Currently it says it is building "lang.mo",
even though it is actually building "domain.mo" inside
lang/LC_MESSAGES/.
Since meson loudly complains if I try to name the display name
"lang/domain.mo", name it with a dash instead of a slash. The actual
name isn't a priority here IMO, and this is nicely readable.
Removed in commit 487d45c1e5 but perhaps
it should not have -- people may have been depending on ensuring those
are built somehow. Even though the internal implementation changed and
it is now built by the all target, let's keep the old target around too.
Now it just aliases the actual build rules, though.
Users may wish to make use of these files for their own purposes.
For example, the -pot and -update-po pseudo targets could be reused in
an alias_target(), and at least one person wanted to reuse the built .mo
files as custom_target input.
Fixes#6227
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
The sysconfig paths are, by default, correct for every OS -- they are
supposed to follow the scheme that python knows about per default.
For some reason, this overrode the scheme to posix_prefix, which is the
default for posix OSes like linux and macOS, but wrong on Windows.
Simply deleting this entirely makes everything that used to work, still
work, and a couple new things start working.
The tool needs to run the preprocessor (but does not actually produce
compiled outputs), and meanwhile ignores lots of flags it doesn't think
it needs. In the case of -D_FORTIFY_SOURCE=... this is only valid if -O
is there too, but otherwise spits out confusing warnings.
The warnings are spurious and can be safely ignored, but in this case
let's go the extra mile and fix g-ir-scanner's upstream bug by removing
the fortify flag first.
Fixes#9161
rsplit(..., 1) always produces exactly one split, by design, there's no
need to then join a 1-element list via a generator comprehension after
extracting the end of it via pop. If this commit message sounds
confusing, then so was I when trying to figure out what this actually
did and if it needed extracting to PythonExternalModule.
Don't just create a .PHONY target which runs a script that magically
generates files ninja doesn't know about. It results in untracked files,
and `meson install` has to run additional commands instead of copying
over files, and then cannot track them to uninstall them later.
I'm not even really sure why it was originally done via a proxy script,
most likely bad legacy design. This is after all one of the oldest
modules...
One side effect of this is that meson doesn't know how to rename
build.CustomTarget files on install (only data files are supported?),
and every file needs to be installed as "domainname.mo" so it must be
named that in-tree too. To prevent clashes, every locale gets its own
locale-specific subdirectory.
Once we are doing that anyway, we can output them to the actual
structure required by the gettext family of functions, and
bindtextdomain() can therefore point to this location if desired. This
might be useful for running localized programs from the build tree.
When sending them to the introspection scanner, we must always filter
all compiler and linker flags, because g-ir-scanner does not accept any
random argument but only a specific subset.
Fixes: #8876
Dylan Baker