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