The check in _ke_is_excluded, which causes GKqueueFileMonitor to
fallback to GPollFileMonitor when it returns TRUE, was made to prevent
file monitor from blocking unmount of removable drives on systems not
supporting O_EVTONLY flag in open. However, since g_mount_can_unmount
always returns TRUE on Unix-like platforms, the check always returns
TRUE on non-standard mount points, which is very likely to cause all
programs on the desktop to use the polling fallback if GNOME is
installed in a different prefix for development. This makes the desktop
sluggish and results in bad developer experience on *BSD.
Kqueue isn't good at detecting rapid file creation and deletion. It
tends to miss events because events returned by the kernel don't include
filename information. Since the size of struct kevent is fixed, it is
probably not possible to extend the API to include file names without
breaking ABI. Therefore, we disables the test here to avoid test failure
that is impossible to fix in a reliable way.
The test 'file' uses non-standard '--bytes' option when running du,
which may cause error on non-GNU systems. To keep the test working,
we skips the du check as if we don't find a du command when du fails.
-export-dynamic is a libtool flag. It is also supported by GCC as an
undocumented flag, but it is not supported by Clang. Since we don't use
libtool in meson, we should use -Wl,--export-dynamic instead.
The Visual Studio 2005 projects have not been updated nor dist'ed in a
while, plus we are directing people using Visual Studio to build using
Meson, so it's time to remove them from the source tree.
In master, it is already possible to build GLib using Visual Studio
using Meson[1] for some time, so we should focus on maintaining only the
Meson build files for building GLib with Visual Studio.
[1]: There are caveats when building with Visual Studio 2008, namely
that one needs to use the mt command to embed the manifests that
are generated with the .exe/DLLs, for all builds, and that in the
case where the compilation hangs on Visual Studio 2008 x64, as a
workaround, should stop the build by terminating all cl.exe tasks
and change the compiler optimization flag from /O2 (full speed) to
/O1 (optimize for size), due to compiler optimization issues.
We have no way to test Solaris builds atm, and it is not even clear how
to detect Solaris systems with meson. It will probably need to be
revisited when we get a proper CI in place.
Change G_FILE_ATTRIBUTE_ACCESS_CAN_TRASH logic to be consistent
with recent g_local_file_trash changes, i.e. set this to FALSE for
locations on system-internal mounts.
https://gitlab.gnome.org/GNOME/glib/issues/251
New bugs appears periodically in nautilus/gvfs/glib components that not
all trashed files are shown in trash:///. It used to be problem mostly
for "bind mounts" and btrfs subvolumes only. Currently, it is also
problem for nfs, cifs and other filesystems, which have been recently
added by commmit 0d69462f on the list of system internal filesystems.
This happens because the trash backend doesn't monitor files on system
internal mounts. Such behavior is not against the trash-spec, however,
we should be consistent within GNOME.
This behavior has the nice side-effect that it solves issues with hangs
on network filesystems: https://gitlab.gnome.org/GNOME/glib/issues/605,
because those are currently on the system internal filesystem list.
https://gitlab.gnome.org/GNOME/glib/issues/251
When over-allocating by inserting values off the end of an array, maybe
expand the array once, rather than twice (once for setting the size and
once for appending the values).
Suggestion by Peter Bloomfield (@peterb) as a follow-up to #1374.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, there was very little coverage of GArray behaviour with
either of the zero_terminated or clear_ arguments to g_array_new() set
to TRUE.
Parameterise the tests and exhaustively expand the coverage to cover all
possible GArray configurations.
This was made possible by the online code coverage report for GLib which
we now have:
https://gnome.pages.gitlab.gnome.org/glib/coverage/glib/garray.c.gcov.html.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795975
Previously, g_array_insert_vals() would crash if called with an index
off the end of the array. This is inconsistent with the behaviour of
other methods (like g_array_set_size()), which will expand the array as
necessary.
Modify g_array_insert_vals() to expand the array as necessary. New array
elements will be cleared to zero if the GArray was constructed with
(clear_ == TRUE).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795975
They do both accept NULL value arrays, but only if the number of
elements in the value array is zero. Fix the annotations and mention
this in the documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795975
It's mostly not used anymore and doesn't do what it says it does.
The docs state that it affects GList, GSList, GNode, GMemChunks, GSignal,
GType n_preallocs and GBSearchArray while:
* GList, GSList and GNode use GSlice and are not affected
* GMemChunks is gone
* GType npreallocs is ignored
It also states that it can be used to force the usage of g_malloc/g_free,
which is handled by G_SLICE=always-malloc now.
The only places where it's used is in signal handling through GBSearchArray
and in GValueArray (deprecated). Since it's unlikely that anyone wants to
reduce allocation sizes just for those cases remove the build option.
This test assumes the subprocess does not print anything else on stdout
other than the dbus address, otherwise g_test_trap_assert_stdout()
fails to match. But if the env running tests has G_MESSAGES_DEBUG=all
then it will also print "PATH=%s".
