On Mon, Jun 22, 2015 at 12:01 AM, Philip Withnall <phi...@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 < > > phi...@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.mustie...@gmail.com> wrote: > > > > > Ok, thanks for clarifying! :) > > > > > > > > > > 2015-05-28 14:40 GMT+02:00 Philip Withnall < > > > > > phi...@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/ModernAutotools > > > > > > > > > > > > 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/GnomeGoals?a > > > > > > > ction=show&redirect=GnomeGoals > > > > > > > > > > > > > > > > > > > > > 2015-05-28 13:47 GMT+02:00 Philip Withnall < > > > > > > > phi...@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