Introduce a DirMaker class that disassembles the path up to '/' and stores all
directories in a list. That list is in creation order and pre-existing
directories are ignored, i.e. creating the two paths
'/usr/share/foo/bar/baz' and '/usr/share/foo/bar/boo' is stored as
[ '/usr/share/foo',
'/usr/share/foo/bar',
'/usr/share/foo/bar/baz',
'/usr/share/foo/bar/boo' ]
This is on the assumption that /usr/share already existed.
After all files have been installed, the list of created directories is
appended in reverse order to the install log. The uninstall script then
triggers rmdir on all directories.
If a custom install script drops files into the directories, removing those
will fail. This matches the current expectation, see the existing warning
"Remember that files created by custom scripts have not been removed."
Unfortunately, this makes the behavior on uninstall inconsistent. Assuming a
non-existing prefix,
ninja install && ninja uninstall
removes all traces of the install.
However,
ninja install && ninja install && ninja uninstall
removes the files only, not the directories as they already existed.
This could be fixed by just unconditionally removing any (emtpy) directories
that we drop files into, at the risk of removing system directories if empty.
For example, one could imagine /etc/foo.conf.d/ to be removed in that case if
it is empty.
https://github.com/mesonbuild/meson/issues/2032
Try to restore the context for SELinux. If we fail on running
'selinuxenabled', quietly ignore the error and continue. If we fail on the
actual restorecon call, we print a message but disable SELinux - chances are
high that if one restorecon fails, others will too and that's likely a system
setup issue.
Fixes#1967
Precompiled headers should generally be compiled with the same flags as
the sources that will include the header. Some deviations are safe,
however, most will cause the compiler to reject the precompiled header
or possibly lead to compiler crashes.
Otherwise, when you have a static helper library written in Vala
that you want to `link_whole` into a shared library you have to
manually add the .vapi file as a source.
The glib-genmarshal tool was rewritten in GLib 2.53.3, and now supports
more command line arguments, such as:
"--pragma-once": emits a "#pragma once" instead of the old header
guards when generating the header file
"--prototypes": emits the marshallers prototype when generating the
source file
"-D,-U": defines and undefines pre-processor symbols
"--include-header": emits an "#include" directive when generating the
source file for the specified header file
Meson should take advantage of these new options, as they can be used to
replace most of the ad hoc build rules that projects are currently using
to implement the same thing.
Instead of mapping each option to a named argument, I used the same
approach as the compile_resources() and generate_gir() methods; the
genmarshal() method now has an 'extra_args' argument that can be used to
pass extra arguments to the glib-genmarshal tool.
In addition to filtering libs out while generating the command-line, we
must also filter them out in find_library() otherwise these libs will be
detected as "found" on Windows with MSVC.
Closes https://github.com/mesonbuild/meson/issues/1509
This commit amends 04a2e6de making
linker.get_std_shared_lib_link_args() always return -shared for
SharedLibrary(es) instead of -bundle. SharedModule(s) get linked with
linker.get_std_shared_module_link_args() which already correctly returns
-bundle.
Before this change -bundle and -install_name ended up being emitted
for Objective-C shared libraries, which caused a linking error.
When dealing with the SharedLibrary or StaticLibrary include
directories, we where not taking into acount that path are relative to
the source tree. With proper helper, this works now. This fixues issue
where the gir may be generated bug from headers found in the prefix.