Hey Emmanuele, Philip On Tue, 2015-06-23 at 17:08 +0100, Emmanuele Bassi wrote:
that's usually better replaced by: autoreconf -if || exit $? test -n $NOCONFIGURE && ./configure $@ Which isn't shorter, but it's pretty much to the point and works fine in jhbuild and autobuilders.
What if your module uses glib-gettext, gtk-doc, or intltool? As I understand it, autoreconf doesn’t know about running glib-gettextize, gtkdocize or intltoolize. I guess the best answer to that would be: • “use gettext rather than glib-gettext or intltool”; and • “fix gtk-doc to not need gtkdocize”[0]. Philip (the other Philip) [0]: https://bugzilla.gnome.org/show_bug.cgi?id=744864
On 23 June 2015 at 16:54, Philip Chimento <philip chimento gmail com> wrote:On Mon, Jun 22, 2015 at 12:01 AM, Philip Withnall < philip tecnocode co uk> wrote:On Sun, 2015-06-21 at 17:56 -0700, Jasper St. Pierre wrote:On Thu, May 28, 2015 at 9:05 AM, Philip Withnall < philip tecnocode co uk> wrote:See literally the first migration item on https://wiki.gnome.org/Projects/GnomeCommon/Migration tl;dr: You can open-code it with essentially: aclocal --install || exit 1 glib-gettextize --force --copy || exit 1 gtkdocize --copy || exit 1 intltoolize --force --copy --automake || exit 1 autoreconf --verbose --force --install -Wno -portability || exit 1 (removing the technologies which you don’t use).Er, I meant to reply to this earlier, but forgot to, I guess. Is there a simpler thing than this, because I still like ". gnome -autogen.sh" more. Seems much simpler.There is not. You are welcome to continue using gnome-autogen.sh if you want to keep a dependency around purely for a build-time shell script. Or you could copy gnome-autogen.sh into your project. We are planning no further changes to gnome-autogen.sh upstream. Note that using gnome-autogen.sh isn’t actually as simple as that; you’re supposed to set various environment variables indicating your dependencies. So a realistic invocation is more like: #!/bin/sh srcdir=`dirname $0` test -z "$srcdir" && srcdir=. PKG_NAME=libgdata (test -f $srcdir/configure.ac) || { echo "**Error**: Directory "\`$srcdir\'" does not look like the top-level $PKG_NAME directory" exit 1 } which gnome-autogen.sh || { echo "You need to install gnome-common from GNOME Git" exit 1 } REQUIRED_PKG_CONFIG_VERSION=0.17.1 REQUIRED_AUTOMAKE_VERSION=1.13 REQUIRED_GTK_DOC_VERSION=1.14 . gnome-autogen.sh "$@"In fact for most projects you can probably just replace ". gnome -autogen.sh" with "autoreconf -if". It's fewer keystrokes ;-) Or "autoreconf -if && ./configure $@" if you want to retain the behaviour of automatically running configure (which I would prefer not to do, if only jhbuild didn't rely on it.) Philip C.On Thu, 2015-05-28 at 08:43 -0700, Jasper St. Pierre wrote:What about the gnome-autogen.sh script? Most of my autogen.sh files just run ". gnome-autogen.sh" On Thu, May 28, 2015 at 6:55 AM, Daniel Mustieles García <daniel mustieles gmail com> wrote:Ok, thanks for clarifying! :) 2015-05-28 14:40 GMT+02:00 Philip Withnall < philip tecnocode co uk>:It’s already sort of tracked as part of the ModernAutotools goal, although that one lost momentum a while ago, so its status needs to be reset: https://wiki.gnome.org/Initiatives/GnomeGoals/ModernAut otools However, since there’s no flag-day-changeover for gnome -common, I’m not sure it’s necessary to have a GNOME Goal. Maintainers hate touching build systems unnecessarily. Philip On Thu, 2015-05-28 at 14:03 +0200, Daniel Mustieles García wrote:Would this make sense to create a GNOME Goal[1] to ease/track the change? [1] https://wiki.gnome.org/action/show/Initiatives/GnomeG oals?a ction=show&redirect=GnomeGoals 2015-05-28 13:47 GMT+02:00 Philip Withnall < philip tecnocode co uk>: Hi all, This cycle, Dave and I are planning for the last ever release of gnome-common. A lot of its macros for deprecated technologies (scrollkeeper?!) have been removed, and the remainder of its macros have found better replacements in autoconf -archive[1], where they can be used by everyone, not just GNOME. We plan to make one last release, and people are welcome to depend on it for as long as they like. However, if you want new hotness, port to the autoconf-archive versions of the macros; but please do it in your own time. There will be no flag day port away from gnome-common. Note that, for example, porting to AX_COMPILER_FLAGS is valuable, but will probably require fixing a number of new compiler warnings in your code due to increased warning flags. We hope this will make your code better in the long run. There’s a migration guide here: https://wiki.gnome.org/Projects/GnomeCommon/Migration We’ve tried to make the transition as easy and smooth as possible, but there will inevitably be hiccups. Please let me know about anything which breaks or doesn’t make sense. First person to complain about -Wswitch-enum gets a prize. For developers --- When building from a tarball of a module which uses the new macros, you will no longer need gnome-common installed. (Although you may not have needed it before.) When building from git, you will need m4 -common[2] or autoconf-archive[1] installed. JHBuild bootstrap installs m4-common automatically, as does gnome-continuous; so you don’t need to worry about that. For packagers --- In the 3.14.0 release, gnome-common installed some early versions of the autoconf-archive macros which conflicted with what autoconf-archive itself installs. It now has a --[with| without]-autoconf-archive configure option to control this. We suggest that all packagers pass --with-autoconf-archive if (and only if) autoconf -archive is packaged on the distribution. See bug #747920[3]. m4-common *must not* be packaged. See its README[2]. m4-common is essentially a caching subset of autoconf -archive. For continuous integrators --- Modules which use the new AX_COMPILER_FLAGS macro gain a new standard --disable-Werror configure flag, which should be used in CI systems (and any other system where spurious compiler warnings should _not_ cause total failure of a build) to disable -Werror. The idea here is that -Werror is enabled by default when building from git, and disabled by default when building from release tarballs and in buildbots. Philip [1]: http://www.gnu.org/software/autoconf-archive/ [2]: https://github.com/desrt/m4-common/ [3]: https://bugzilla.gnome.org/show_bug.cgi?id=747920_______________________________________________ desktop-devel-list mailing list desktop-devel-list gnome org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Attachment:
signature.asc
Description: This is a digitally signed message part