Re: Death of gnome-common
- From: "Jasper St. Pierre" <jstpierre mecheye net>
- To: Philip Withnall <philip tecnocode co uk>
- Cc: GNOME release team <release-team gnome org>, desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: Death of gnome-common
- Date: Sun, 21 Jun 2015 17:56:24 -0700
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.
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 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?action=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
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
--
Jasper
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]