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.