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).
Philip
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
> <[email protected]> wrote:
> > Ok, thanks for clarifying! :)
> >
> > 2015-05-28 14:40 GMT+02:00 Philip Withnall <[email protected]>:
> >>
> >> 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?action=show&redirect=GnomeGoals
> >> >
> >> >
> >> > 2015-05-28 13:47 GMT+02:00 Philip Withnall <[email protected]>:
> >> > 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
> >> > [email protected]
> >> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >> >
> >> >
> >>
> >
> >
> > _______________________________________________
> > desktop-devel-list mailing list
> > [email protected]
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
