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 "$@"
> > 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/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 <
> > > > > > 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