- Sep 01, 2018
-
-
Debarshi Ray authored
-
- Aug 20, 2018
-
-
Khaled Hosny authored
-
- Aug 16, 2018
-
-
Debarshi Ray authored
-
Debarshi Ray authored
-
Debarshi Ray authored
Building with AX_CHECK_ENABLE_DEBUG([yes]), which is what happens by default for non-release builds, turns off compiler optimizations and overrides any optimization specified via CFLAGS in the build environment. This means that the nightly Flatpaks, and almost all other non-release builds, are built without any optimization. This triggers a warning about _FORTIFY_SOURCE requiring optimization, on distributions that build with _FORTIFY_SOURCE, when running g-ir-scanner to generate Goa-1.0.gir. Since g-ir-scanner uses Python's distutils.ccompiler, the compiler flags with which Python itself was built gets tagged into the compilation of the generated code that's used to generate the GIR. If the Python installation being used was built with _FORTIFY_SOURCE, the warning is triggered. It can be useful to turn off compiler optimizations to get a better debugging experience, but it becomes a problem if it stomps over the build environment while doing so. The person doing the builds should should get to decide between ease of debugging and other factors. After all, debugging is not the only thing that a developer does. One can use GDB reasonably well with the Autoconf default, which also happens to be what most distributions use, of "-g O2". This wouldn't have been such a problem if AX_CHECK_ENABLE_DEBUG attached its flags before the values from the environment instead of after, because in case of multiple -O options, the last such option is the one that's effective. Thankfully, "no" doesn't override the environment, which is what happens for release builds, and distributions generally set their own CFLAGS. Otherwise every single user-facing build would have been broken. Note that any release build without CFLAGS set in the environment would neither get debug symbols (ie., no "-g") nor any compiler optimization because AX_CHECK_ENABLE_DEBUG always suppresses the Autoconf defaults of "-g -O2". One solution could have been to default to "info" for non-release builds and recommend the use of --enable-debug=info while building from Git, but that would not address release builds without CFLAGS. Given that the only other thing the macro does is to define the NDEBUG pre-processor macro when debugging is set to "no", which isn't widely used in the GLib-based GNOME platform [1], it seems better to just remove it altogether. [1] glib/gio/xdgmime is the only widely used code path where assert(3) is used. It's also used in gio/kqueue/dep-list.c, which is *BSD-specific and in GTK+'s Broadway backend. All those can probably be replaced with g_assert*. https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/10
-
Debarshi Ray authored
GCC 8 introduced -Wcast-function-type. It is enabled by -Wextra, which is on the AX_COMPILER_FLAGS list. Unfortunately, this cannot be sanely used with the GNOME platform. It is exceedingly common practice to specify a function as a callback that ignores some of the trailing parameters passed to it. In fact, the following snippet that's part of the g_list_copy_deep documentation triggers -Wcast-function-type: another_list = g_list_copy_deep (list, (GCopyFunc) g_object_ref, NULL); Disabling warnings like this does go against the recommendation of the AX_COMPILER_FLAGS documentation, which suggests the use of #pragmas instead. However, unlike passing the flags through the command line, attempts to ignore -Wcast-function-type through a #pragma will trigger -Wpragmas on older versions of GCC, and, ironically, using G_GNUC_CHECK_VERSION to conditionally disable it on newer compilers will trigger -Wexpansion-to-defined, again, because of -Wextra.
-
- Jul 20, 2018
-
-
Iñigo Martínez authored
Although #FooObject style links are properly created from the source code, there are two content files, `goa-daemon.xml` and `goa-overview.xml`, that should also be expanded to generate links from tokens. https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/2
-
Iñigo Martínez authored
Meson's configuration object `set` method receives a boolean value. On the other hand, there are a set of options related to the type of accounts supported by `gnome-online-accounts`. These options can be used as the boolean parameter directly in the `set` method, so there is no need to use a conditional statements. https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/2
-
Iñigo Martínez authored
Following autotools build files, the project name was set to `GNOME Online Accounts`, so a variable was created to be used as package datadir and gettext domain set to `gnome-online-accounts` string. However, recently the project name has been changed to `gnome-online-accounts` so the variable used as package datadir and gettext domain is not necessary anymore. https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/2
-
Debarshi Ray authored
-
Iñigo Martínez authored
The `HAVE_TIMERFD` define should only be set when the test code compiles. When the code compiles we can ensure that `HAVE_TIMERFD` has to be unconditionally defined, so the auxiliary `have_timerfd` variable used for this is unnecessary. https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/2
-
- Jul 19, 2018
-
-
-
Emmanuele Bassi authored
Build against GLib 2.57.2 See merge request GNOME/gnome-online-accounts!8
-
Emmanuele Bassi authored
The g_clear_pointer() macro in GLib gained a bit of type safety when using GCC and GCC-compatible compilers; now, though, GCC really does not like it when people cast the destroy argument to GDestroyNotify. The macro was added precisely to avoid the need to cast the arguments for g_clear_pointer(), so the cast to GDestroyNotify was unnecessary to begin with.
-
- Jul 18, 2018
-
-
Debarshi Ray authored
-
Iñigo Martínez authored
Meson is a build system focused on speed an ease of use, which helps speeding up the software development. This patch adds Meson support alongside Autotools. Known issue: * #FooObject style links in gtk-doc markup don't resolved into HTML links in the generated HTML. https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/2 https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/3
-
Debarshi Ray authored
The GSettings is only used by the backend to determine which providers to load.
-
Debarshi Ray authored
The gtk-doc HTML isn't installed by default, so it makes sense to not install the goa-daemon(8) man page either for consistency.
-
Debarshi Ray authored
The --enable-documentation option is only about the goa-daemon(8) man page, and nothing else. The gtk-doc HTML pages are controlled by the --enable-gtk-doc option.
-
- Jun 27, 2018
-
-
Cédric Valmary authored
-
- Apr 17, 2018
-
-
Debarshi Ray authored
-
Debarshi Ray authored
-
Debarshi Ray authored
Provider factories were only used for Telepathy support, and are now unused. This reverts commit faf55197. https://bugzilla.gnome.org/show_bug.cgi?id=795322
-
Debarshi Ray authored
Provider factories were only used for Telepathy support, and are going to be removed. This reverts commit a45fba78. https://bugzilla.gnome.org/show_bug.cgi?id=795322
-
Debarshi Ray authored
Provider factories were only used for Telepathy support, and are going to be removed. This reverts commit 1a8bfdf9. https://bugzilla.gnome.org/show_bug.cgi?id=795322
-
Debarshi Ray authored
Provider factories were only used for Telepathy support, and are going to be removed. This reverts commit a990c61c. https://bugzilla.gnome.org/show_bug.cgi?id=795322
-
Debarshi Ray authored
This was only necessary to initialize the backends at startup. The Telepathy provider was the only backend that needed initialization, and it has now been removed. This reverts commit ee7318aa. https://bugzilla.gnome.org/show_bug.cgi?id=795322
-
Debarshi Ray authored
This vfunc was only used by the Telepathy provider, and is now unused. This reverts commit e2f64a91. https://bugzilla.gnome.org/show_bug.cgi?id=795322
-
Debarshi Ray authored
Backend-specific initialization at startup was only used by the Telepathy provider, and is now unused. This reverts commits 692bdebf and 6d02cb7f. https://bugzilla.gnome.org/show_bug.cgi?id=795322
-
Debarshi Ray authored
The Empathy / Telepathy stack is no longer as strongly maintained as it used to be, and the consensus in GNOME is to deprecate it. Moreover, the Telepathy integration in GOA doesn't actually buy the user any benefits. The original plan was to disable Empathy's own account management UI (ie. empathy-accounts), but that never happened. So, we ended up with two UIs, which at times had slightly divergent behaviour - Microsoft account added via OAuth2 / XMPP versus raw passwords / legacy pre-XMPP protocol. These days we have Polari, which also has its own accounts UI, which is in keeping with its status as a non-core application. https://bugzilla.gnome.org/show_bug.cgi?id=795322
-
- Apr 16, 2018
-
-
Debarshi Ray authored
-
- Apr 09, 2018
-
-
Marek Cernocky authored
-
- Mar 19, 2018
-
-
Boyuan Yang authored
-
- Mar 15, 2018
-
-
Debarshi Ray authored
-
- Mar 13, 2018
-
-
Stas Solovey authored
-
- Mar 12, 2018
-
-
Claude Paroz authored
-
- Mar 11, 2018
-
-
Anders Jonsson authored
-
- Mar 10, 2018
-
-
Chao-Hsiung Liao authored
-
- Mar 07, 2018
-
-
Milo Casagrande authored
-
- Mar 06, 2018
-
-
Efstathios Iosifidis authored
-