Re: Death of gnome-common

[Emmanuele Bassi <ebassi gmail com>]

Hi Philip;

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.

Ciao,
 Emmanuele.


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/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
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
https://www.bassi.io
[ ] ebassi [ gmail com]