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
