Re: Death of gnome-common
- From: Emmanuele Bassi <ebassi gmail com>
- To: Philip Withnall <philip tecnocode co uk>
- Cc: Philip Chimento <philip chimento gmail com>, desktop-devel-list <desktop-devel-list gnome org>, GNOME release team <release-team gnome org>
- Subject: Re: Death of gnome-common
- Date: Wed, 24 Jun 2015 08:56:38 +0100
Hi;
On 23 June 2015 at 23:41, Philip Withnall <philip tecnocode co uk> wrote:
Hey Emmanuele, Philip
On Tue, 2015-06-23 at 17:08 +0100, Emmanuele Bassi wrote:
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.
What if your module uses glib-gettext, gtk-doc, or intltool?
I do hope that, if you're using glib-gettext or intltool, you spend a
little bit of time to port to upstream gettext instead.
As for gtk-doc, yes: sadly we still need gtkdocize.
I guess the best answer to that would be:
• “use gettext rather than glib-gettext or intltool”; and
• “fix gtk-doc to not need gtkdocize”[0].
Philip (the other Philip)
[0]: https://bugzilla.gnome.org/show_bug.cgi?id=744864
Yep. :-)
In the meantime, you can still pile on commands to the autogen.sh —
that's the reason why we have a script instead of telling people to
just run `autoreconf` directly.
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/ModernAut
otools
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/GnomeG
oals?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]
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]