Hi;

On 23 June 2015 at 23:41, Philip Withnall <phi...@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.chime...@gmail.com>
>> wrote:
>> > On Mon, Jun 22, 2015 at 12:01 AM, Philip Withnall <
>> > phi...@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 <
>> > > > 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.
>> > >
>> > > 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.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/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 <
>> > > > > > > > > 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-l...@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>>
>>



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Reply via email to