Re: Integrate ITS Tool with gettext and Autotools (Was: Re: Death of gnome-common)
On Fri, Oct 02, 2015 at 04:48:31PM -0400, Shaun McCance wrote: > On Fri, 2015-10-02 at 19:55 +0200, Sébastien Wilmet wrote: > > So a solution is to add the generated *.pot files to Git. > > > > Is there another solution? > > This is what yelp and yelp-xsl do. They have XML files of translated > strings for use in XSLT. It's a home-brewed XSLT gettext system. Here's > the Makefile.am that manages the POT file: > > https://git.gnome.org/browse/yelp-xsl/tree/xslt/common/domains/Makefile > .am > > Here's the POT file in git: > > https://git.gnome.org/browse/yelp-xsl/tree/xslt/common/domains/yelp-xsl > .pot > > Here's the POTFILES.in: > > https://git.gnome.org/browse/yelp-xsl/tree/po/POTFILES.in Thanks for your quick answer. I'll do the same in GtkSourceView then. Maybe the Autotools/gettext/VCS integration should be documented on: http://itstool.org/documentation/ > Yes, putting generated files in git is dirty. But it does work, and I > haven't gotten any complaints about it. If somebody has a suggestion on > how to do this differently, I'm all ears. >From what I understand, I think it's because gettext doesn't support files in POTFILES.in that need to be generated (generated in builddir of course). > Daiki has been working on adding ITS support to gettext, so you will be > able to do arbitrary XML with ITS without external tools. Here's his > work-in-progress: > > http://git.savannah.gnu.org/cgit/gettext.git/commit/?h=wip/ueno/its2 > =7a17583f Oh, great! > I don't think gettext's XML support will grow to the point where it can > handle complex documentation, but this is probably the way forward for > simple XML data files. To mark XML attributes as translatable, a common thing to do is to prefix them with an underscore. Intltool supports that, but not gettext AFAIK. If the ITS branch supports that, it would cover lots of simple cases. Cheers, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Integrate ITS Tool with gettext and Autotools (Was: Re: Death of gnome-common)
On Sat, Oct 3, 2015 at 12:49 AM, Alexandre Franke < alexandre.fra...@gmail.com> wrote: > On Sat, Oct 3, 2015 at 4:40 AM, Philip Chimento >wrote: > > For what it's worth, I break that rule for .pot files in my own projects, > > because adding them to Git makes it easier for people who aren't > comfortable > > with the command line to contribute translations. > > Are you updating the pot file every time you change strings in your > source code? This is not the recommended workflow for GNOME > translation and you're giving bad habits to anyone you're pointing to > this file. Damned lies provides an up to date pot file for all modules > and ensures translations are never based on the wrong file. > I'm talking about non-Gnome projects; when there is a different recommended workflow that translators are used to, I would use that. But to answer your question; no, I purposely don't update the .pot file every time I change a string. I only update the .pot file when I want to release new strings to translators, some time before a release. Regards, -- Philip ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Integrate ITS Tool with gettext and Autotools (Was: Re: Death of gnome-common)
On Sat, Oct 3, 2015 at 4:40 AM, Philip Chimentowrote: > For what it's worth, I break that rule for .pot files in my own projects, > because adding them to Git makes it easier for people who aren't comfortable > with the command line to contribute translations. Are you updating the pot file every time you change strings in your source code? This is not the recommended workflow for GNOME translation and you're giving bad habits to anyone you're pointing to this file. Damned lies provides an up to date pot file for all modules and ensures translations are never based on the wrong file. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Integrate ITS Tool with gettext and Autotools (Was: Re: Death of gnome-common)
Hi, On Wed, Jun 24, 2015 at 02:17:52PM +0100, Emmanuele Bassi wrote: > On 24 June 2015 at 14:13, Michael Catanzarowrote: > > On Wed, 2015-06-24 at 08:56 +0100, Emmanuele Bassi wrote: > >> 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. > > > > Has anyone written a guide on how to do this? > > It's the same guide as using gettext. Upstream gettext recognises > desktop files, GSettings schemas, as well as GtkBuilder XML > definitions. > > Sadly, it's still in use for AppData XML, but for that (and any other > XML-based format) there's itstool, which is also used by the > documentation team for the application help: > >http://itstool.org/ I have a question about how to integrate ITS Tool with upstream gettext and Autotools (and Git). I have a branch in GtkSourceView to use upstream gettext and itstool: https://git.gnome.org/browse/gtksourceview/log/?h=wip/dont-use-intltool ITS Tool generates *.pot files that can be added to the POTFILES.in. I've tried to not add the generated *.pot files to Git, because generated files should not be added to the version control system. But then there are problems with builddir != srcdir. For tarballs the solution is easy: distribute the generated sub *.pot files in the tarball. But when compiling from the git repository, some make targets don't work with builddir != srcdir. So a solution is to add the generated *.pot files to Git. Is there another solution? The gettext documentation doesn't recommend to add generated files in the POTFILES.in: https://www.gnu.org/software/gettext/manual/html_node/po_002fPOTFILES_002ein.html When a file is present in POTFILES.in, the make target supposes that the file is in srcdir. So adding a make target (in a gettext Rules file that is added to the po/Makefile) to build that file in builddir won't help when builddir != srcdir. Maybe a solution is to modify po/Makefile.in.in, like it is done in GTK+ (but not for using ITS Tool). But I'd rather keep things simple. Is there a recommended way of doing things? Thanks in advance, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Integrate ITS Tool with gettext and Autotools (Was: Re: Death of gnome-common)
On Fri, 2015-10-02 at 19:55 +0200, Sébastien Wilmet wrote: > Hi, > > On Wed, Jun 24, 2015 at 02:17:52PM +0100, Emmanuele Bassi wrote: > > On 24 June 2015 at 14:13, Michael Catanzaro> > wrote: > > > On Wed, 2015-06-24 at 08:56 +0100, Emmanuele Bassi wrote: > > > > 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. > > > > > > Has anyone written a guide on how to do this? > > > > It's the same guide as using gettext. Upstream gettext recognises > > desktop files, GSettings schemas, as well as GtkBuilder XML > > definitions. > > > > Sadly, it's still in use for AppData XML, but for that (and any > > other > > XML-based format) there's itstool, which is also used by the > > documentation team for the application help: > > > >http://itstool.org/ > > I have a question about how to integrate ITS Tool with upstream > gettext > and Autotools (and Git). > > I have a branch in GtkSourceView to use upstream gettext and itstool: > https://git.gnome.org/browse/gtksourceview/log/?h=wip/dont-use-intlto > ol > > ITS Tool generates *.pot files that can be added to the POTFILES.in. > I've tried to not add the generated *.pot files to Git, because > generated files should not be added to the version control system. > But > then there are problems with builddir != srcdir. For tarballs the > solution is easy: distribute the generated sub *.pot files in the > tarball. But when compiling from the git repository, some make > targets > don't work with builddir != srcdir. > > So a solution is to add the generated *.pot files to Git. > > Is there another solution? This is what yelp and yelp-xsl do. They have XML files of translated strings for use in XSLT. It's a home-brewed XSLT gettext system. Here's the Makefile.am that manages the POT file: https://git.gnome.org/browse/yelp-xsl/tree/xslt/common/domains/Makefile .am Here's the POT file in git: https://git.gnome.org/browse/yelp-xsl/tree/xslt/common/domains/yelp-xsl .pot Here's the POTFILES.in: https://git.gnome.org/browse/yelp-xsl/tree/po/POTFILES.in Yes, putting generated files in git is dirty. But it does work, and I haven't gotten any complaints about it. If somebody has a suggestion on how to do this differently, I'm all ears. Daiki has been working on adding ITS support to gettext, so you will be able to do arbitrary XML with ITS without external tools. Here's his work-in-progress: http://git.savannah.gnu.org/cgit/gettext.git/commit/?h=wip/ueno/its2 =7a17583f I don't think gettext's XML support will grow to the point where it can handle complex documentation, but this is probably the way forward for simple XML data files. > The gettext documentation doesn't recommend to add generated files in > the POTFILES.in: > https://www.gnu.org/software/gettext/manual/html_node/po_002fPOTFILES > _002ein.html > > When a file is present in POTFILES.in, the make target supposes that > the > file is in srcdir. So adding a make target (in a gettext Rules file > that > is added to the po/Makefile) to build that file in builddir won't > help > when builddir != srcdir. > > Maybe a solution is to modify po/Makefile.in.in, like it is done in > GTK+ > (but not for using ITS Tool). But I'd rather keep things simple. > > Is there a recommended way of doing things? > > Thanks in advance, > Sébastien > ___ > 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
Re: Integrate ITS Tool with gettext and Autotools (Was: Re: Death of gnome-common)
On Fri, Oct 2, 2015 at 10:55 AM, Sébastien Wilmetwrote: > I've tried to not add the generated *.pot files to Git, because > generated files should not be added to the version control system. For what it's worth, I break that rule for .pot files in my own projects, because adding them to Git makes it easier for people who aren't comfortable with the command line to contribute translations. Regards, -- Philip ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On 16 August 2015 at 10:31, Sébastien Wilmet swil...@gnome.org wrote: Hi, Hi Sébastien, On Thu, May 28, 2015 at 12:47:47PM +0100, Philip Withnall wrote: 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. I've migrated GtkSourceView, and now when running autogen.sh I see those messages: + glib-gettextize --force --copy Copying file po/Makefile.in.in Please add the files codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /home/seb/jhbuild/share/aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file. You will also need config.guess and config.sub, which you can get from ftp://ftp.gnu.org/pub/gnu/config/. Is it normal? We don't want to add those m4 files on git. For autoconf-archive macros, we have chosen the preferred option, i.e. adding a dependency on autoconf-archive instead of copying the macros. So for gettext we want to do the same. 'make distcheck' passes, but the listed macros above are not distributed in tarballs. --install has been added to the ACLOCAL_AMFLAGS. Do you know what's wrong? Do we need to do something about it? Use upstream gettext instead old/unmaintained glib-gettext, patch here [1] [1] https://bugzilla.gnome.org/show_bug.cgi?id=754037 -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Fri, Aug 21, 2015 at 04:18:09PM -0500, Michael Catanzaro wrote: On Sun, 2015-08-16 at 11:31 +0200, Sébastien Wilmet wrote: --install has been added to the ACLOCAL_AMFLAGS. You don't want to touch that (in Makefile.am) anymore; see: https://mail.gnome.org/archives/desktop-devel-list/2015-June/msg9.html https://mail.gnome.org/archives/desktop-devel-list/2015-June/msg00021.html I just followed the wiki page. There is still: See an example of setting ACLOCAL_AMFLAGS in libgdata. with a link to a commit that adds --install to ACLOCAL_AMFLAGS. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Tue, Aug 18, 2015 at 08:36:43AM +0100, Philip Withnall wrote: Do you know what's wrong? Do we need to do something about it? Just ignore the message. Added to the wiki, in the FAQ. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Sat, 2015-08-22 at 10:45 +0200, Sébastien Wilmet wrote: On Fri, Aug 21, 2015 at 04:18:09PM -0500, Michael Catanzaro wrote: On Sun, 2015-08-16 at 11:31 +0200, Sébastien Wilmet wrote: --install has been added to the ACLOCAL_AMFLAGS. You don't want to touch that (in Makefile.am) anymore; see: https://mail.gnome.org/archives/desktop-devel-list/2015-June/msg000 09.html https://mail.gnome.org/archives/desktop-devel-list/2015-June/msg000 21.html I just followed the wiki page. There is still: See an example of setting ACLOCAL_AMFLAGS in libgdata. with a link to a commit that adds --install to ACLOCAL_AMFLAGS. Fixed; thanks for the heads-up. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Sat, 2015-08-22 at 12:11 +0200, Sébastien Wilmet wrote: On Tue, Aug 18, 2015 at 08:36:43AM +0100, Philip Withnall wrote: Do you know what's wrong? Do we need to do something about it? Just ignore the message. Added to the wiki, in the FAQ. The messages are coming from glib-gettextize, which we've already agreed we should not use anymore. I've updated the wiki again to clarify. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Sun, 2015-08-16 at 11:31 +0200, Sébastien Wilmet wrote: --install has been added to the ACLOCAL_AMFLAGS. You don't want to touch that (in Makefile.am) anymore; see: https://mail.gnome.org/archives/desktop-devel-list/2015-June/msg9.h tml https://mail.gnome.org/archives/desktop-devel-list/2015-June/msg00021.h tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
Hey, On Sun, 2015-08-16 at 11:31 +0200, Sébastien Wilmet wrote: On Thu, May 28, 2015 at 12:47:47PM +0100, Philip Withnall wrote: 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. I've migrated GtkSourceView, and now when running autogen.sh I see those messages: + glib-gettextize --force --copy Copying file po/Makefile.in.in Please add the files codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /home/seb/jhbuild/share/aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file. You will also need config.guess and config.sub, which you can get from ftp://ftp.gnu.org/pub/gnu/config/. Is it normal? We don't want to add those m4 files on git. For autoconf-archive macros, we have chosen the preferred option, i.e. adding a dependency on autoconf-archive instead of copying the macros. So for gettext we want to do the same. 'make distcheck' passes, but the listed macros above are not distributed in tarballs. --install has been added to the ACLOCAL_AMFLAGS. They should be automatically concatenated to the aclocal.m4 script in the tarball, if they are actually used by any of the build system. Do you know what's wrong? Do we need to do something about it? Just ignore the message. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
Sébastien Wilmet swil...@gnome.org writes: I've migrated GtkSourceView, and now when running autogen.sh I see those messages: + glib-gettextize --force --copy Copying file po/Makefile.in.in Please add the files codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /home/seb/jhbuild/share/aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file. You will also need config.guess and config.sub, which you can get from ftp://ftp.gnu.org/pub/gnu/config/. Is it normal? We don't want to add those m4 files on git. For autoconf-archive macros, we have chosen the preferred option, i.e. adding a dependency on autoconf-archive instead of copying the macros. So for gettext we want to do the same. Since those files are not used by glib-gettextize nor glib-gettext.m4, I suppose you can simply ignore the message. The m4 files except gettext.m4 were needed to compile bundled libintl, which glib-gettextize abandoned long ago, and gettext.m4 only defines AM_GNU_GETTEXT_*, which are not invoked when glib-gettext.m4 is used. Regards, -- Daiki Ueno ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Mon, Aug 17, 2015 at 08:06:15PM +0900, Daiki Ueno wrote: Sébastien Wilmet swil...@gnome.org writes: I've migrated GtkSourceView, and now when running autogen.sh I see those messages: + glib-gettextize --force --copy Copying file po/Makefile.in.in Please add the files codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /home/seb/jhbuild/share/aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file. You will also need config.guess and config.sub, which you can get from ftp://ftp.gnu.org/pub/gnu/config/. Is it normal? We don't want to add those m4 files on git. For autoconf-archive macros, we have chosen the preferred option, i.e. adding a dependency on autoconf-archive instead of copying the macros. So for gettext we want to do the same. Since those files are not used by glib-gettextize nor glib-gettext.m4, I suppose you can simply ignore the message. The m4 files except gettext.m4 were needed to compile bundled libintl, which glib-gettextize abandoned long ago, and gettext.m4 only defines AM_GNU_GETTEXT_*, which are not invoked when glib-gettext.m4 is used. Ok thanks. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
Hi, On Thu, May 28, 2015 at 12:47:47PM +0100, Philip Withnall wrote: 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. I've migrated GtkSourceView, and now when running autogen.sh I see those messages: + glib-gettextize --force --copy Copying file po/Makefile.in.in Please add the files codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4 progtest.m4 from the /home/seb/jhbuild/share/aclocal directory to your autoconf macro directory or directly to your aclocal.m4 file. You will also need config.guess and config.sub, which you can get from ftp://ftp.gnu.org/pub/gnu/config/. Is it normal? We don't want to add those m4 files on git. For autoconf-archive macros, we have chosen the preferred option, i.e. adding a dependency on autoconf-archive instead of copying the macros. So for gettext we want to do the same. 'make distcheck' passes, but the listed macros above are not distributed in tarballs. --install has been added to the ACLOCAL_AMFLAGS. Do you know what's wrong? Do we need to do something about it? The GtkSourceView repo: https://git.gnome.org/browse/gtksourceview/ Thanks, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Sat, 2015-05-30 at 08:09 -0500, Michael Catanzaro wrote: This is a nit, but I think the 'set -x' to 'set +x' at the end of the sample autogen.sh is too expansive, since it results in the conditional tests being printed as independent statements: Another problem is that the 'set +x' gets printed as a command. I've changed the wiki page to use this instead: { set +x; } 2/dev/null ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Tue, 2015-06-23 at 22:24 -0500, Michael Catanzaro wrote: On Tue, 2015-06-23 at 08:33 +0100, Philip Withnall wrote: As Kalev says, we should ensure this still builds with various distros. RHEL7 is fine. Debian stable (Jessie) has 1.14. Fedora has had ≥ 1.13 for a long time. Arch has 1.15. FreeBSD has 1.15. So unless anybody objects, I think a hard dependency on automake 1.13 would be fine. Would you mind updating the wiki page to match your suggestions? I guess we can simply remove the ACLOCAL_AMFLAGS line from Makefile.am, since autogen.sh calls aclocal --install. Correct? (This works for me.) Sounds good. libtoolize complains about it: libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. But I guess libtoolize is wrong. Is there an upstream bug report? Probably also makes sense to update https://wiki.gnome.org/Initiatives/GnomeGoals/ModernAutotools which is a separate, though related, goal. We should also remove mention of AX_REQUIRE_DEFINED([APPDATA_XML]) since APPDATA_XML is obsoleted by APPSTREAM_XML. Preferably change it to AX_REQUIRE_DEFINED([APPSTREAM_XML]). I guess aclocal --install and autoreconf --install are redundant, and we just need to run aclocal first because we run glib-gettextize, intltoolize, and gtkdocize before autoreconf? Moving autoreconf to the top of the allows me to drop use of aclocal from my autogen.sh: set -x autoreconf --verbose --force --install -Wno-portability || exit 1 glib-gettextize --force --copy || exit 1 intltoolize --force --copy --automake || exit 1 set +x This works with epiphany's build system (though it doesn't use gtkdocize). I also suspect it's wrong to use both glib-gettextize and intltoolize in autogen.sh, but I don't pretend to understand these tools It is, but that’s an example file and the instructions do say to drop any -ize programs which your module doesn’t use. Suggestions welcome for ways to make this clearer on the wiki page (or just edit it!). Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
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=showredirect=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
Re: Death of gnome-common
On Wed, 2015-06-24 at 22:38 +0200, Michael Biebl wrote: 2015-06-24 9:56 GMT+02:00 Emmanuele Bassi eba...@gmail.com: On 23 June 2015 at 23:41, Philip Withnall phi...@tecnocode.co.uk wrote: 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. Interesting. Is intltool considered deprecated nowadays? If so, where can I read more about it? I would consider it discouraged because it’s effectively a wrapper around gettext, from the days when gettext was unmaintained and didn’t support the tools people wanted. Now gettext is actively (and well!) maintained, intltool is no longer needed. At least, that’s how I understand it. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
Hi, 2015-06-24 9:56 GMT+02:00 Emmanuele Bassi eba...@gmail.com: On 23 June 2015 at 23:41, Philip Withnall phi...@tecnocode.co.uk wrote: 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. Interesting. Is intltool considered deprecated nowadays? If so, where can I read more about it? Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Wed, 2015-06-24 at 08:56 +0100, Emmanuele Bassi wrote: 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. Has anyone written a guide on how to do this? I thought intltool was preferred. We definitely need better documentation for this. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Wed, 2015-06-24 at 09:21 +0100, Philip Withnall wrote: libtoolize complains about it: libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. But I guess libtoolize is wrong. Is there an upstream bug report? No need. I have libtool 2.4.2 provided by Fedora 22, but I see in the libtool 2.4.3 changelog: - The libtoolize program now advises use of the new Autoconf AC_CONFIG_MACRO_DIRS declaration. If you follow that advice, all your developers will need at least autoconf-2.70 and automake-1.13 to rebootstrap your probject. If you still need to support bootstrap with older Autotools, then you should add the following to your configure.ac file: m4_ifndef([AC_CONFIG_MACRO_DIRS], [m4_define([AC_CONFIG_MACRO_DIRS], m4_defn([AC_CONFIG_MACRO_DIR]))]) I guess that should have read your developers will need at least autoconf-2.70 OR automake-1.13 since AC_CONFIG_MACRO_DIRS is provided by Automake, but actually I see no reason to use AC_CONFIG_MACRO_DIRS at all: AC_CONFIG_MACRO_DIR seems to work just fine. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Wed, 2015-06-24 at 08:57 -0500, Michael Catanzaro wrote: On Wed, 2015-06-24 at 14:17 +0100, Emmanuele Bassi wrote: Sadly, it's still in use for AppData XML, but for that (and any other XML-based format) there's itstool, which is also used by the documentation team for the application help: http://itstool.org/ I will wait for someone to replace intltool with itstool in some module that uses appdata, so I have an example to follow. I'm definitely not up for learning yet another language to figure out how to do this from scratch. I’ve got a patch which adds support for AppData to gettext, but it’s stalled on FSF copyright assignment faff. I’m not sure I’ve ever come across such a big barrier to contribution. https://savannah.gnu.org/bugs/?45305 Anyway, ranting aside, here’s the associated branch to port Hitori to gettext, including AppData: https://git.gnome.org/browse/hitori/log/?h=wip/pwithnall/gettext Upstream gettext also has a useful gtk-3 example project: http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext -tools/examples/hello-c-gnome3 Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
Hi; On 24 June 2015 at 14:13, Michael Catanzaro mcatanz...@gnome.org wrote: On Wed, 2015-06-24 at 08:56 +0100, Emmanuele Bassi wrote: 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. Has anyone written a guide on how to do this? It's the same guide as using gettext. Upstream gettext recognises desktop files, GSettings schemas, as well as GtkBuilder XML definitions. Sadly, it's still in use for AppData XML, but for that (and any other XML-based format) there's itstool, which is also used by the documentation team for the application help: http://itstool.org/ I thought intltool was preferred. It was, until gettext got to cover its uses. We definitely need better documentation for this. Indeed we do. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Wed, 2015-06-24 at 14:17 +0100, Emmanuele Bassi wrote: Sadly, it's still in use for AppData XML, but for that (and any other XML-based format) there's itstool, which is also used by the documentation team for the application help: http://itstool.org/ I will wait for someone to replace intltool with itstool in some module that uses appdata, so I have an example to follow. I'm definitely not up for learning yet another language to figure out how to do this from scratch. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Wed, 2015-06-24 at 08:31 -0500, Michael Catanzaro wrote: On Wed, 2015-06-24 at 09:21 +0100, Philip Withnall wrote: libtoolize complains about it: libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. But I guess libtoolize is wrong. Is there an upstream bug report? No need. I have libtool 2.4.2 provided by Fedora 22, but I see in the libtool 2.4.3 changelog: - The libtoolize program now advises use of the new Autoconf AC_CONFIG_MACRO_DIRS declaration. If you follow that advice, all your developers will need at least autoconf-2.70 and automake-1.13 to rebootstrap your probject. If you still need to support bootstrap with older Autotools, then you should add the following to your configure.ac file: m4_ifndef([AC_CONFIG_MACRO_DIRS], [m4_define([AC_CONFIG_MACRO_DIRS], m4_defn([AC_CONFIG_MACRO_DIR]))]) I guess that should have read your developers will need at least autoconf-2.70 OR automake-1.13 since AC_CONFIG_MACRO_DIRS is provided by Automake, but actually I see no reason to use AC_CONFIG_MACRO_DIRS at all: AC_CONFIG_MACRO_DIR seems to work just fine. Yes, as I understand it, AC_CONFIG_MACRO_DIR is just a single-directory version of AC_CONFIG_MACRO_DIRS, and they function equivalently. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
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/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?a ction=showredirect=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
Re: Death of gnome-common
Hi Philip; 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. 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/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?a ction=showredirect=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
Re: Death of gnome-common
On Tue, 2015-06-23 at 08:33 +0100, Philip Withnall wrote: As Kalev says, we should ensure this still builds with various distros. RHEL7 is fine. Debian stable (Jessie) has 1.14. Fedora has had ≥ 1.13 for a long time. Arch has 1.15. FreeBSD has 1.15. So unless anybody objects, I think a hard dependency on automake 1.13 would be fine. Would you mind updating the wiki page to match your suggestions? I guess we can simply remove the ACLOCAL_AMFLAGS line from Makefile.am, since autogen.sh calls aclocal --install. Correct? (This works for me.) libtoolize complains about it: libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. But I guess libtoolize is wrong. Probably also makes sense to update https://wiki.gnome.org/Initiatives/GnomeGoals/ModernAutotools which is a separate, though related, goal. We should also remove mention of AX_REQUIRE_DEFINED([APPDATA_XML]) since APPDATA_XML is obsoleted by APPSTREAM_XML. I guess aclocal --install and autoreconf --install are redundant, and we just need to run aclocal first because we run glib-gettextize, intltoolize, and gtkdocize before autoreconf? Moving autoreconf to the top of the allows me to drop use of aclocal from my autogen.sh: set -x autoreconf --verbose --force --install -Wno-portability || exit 1 glib-gettextize --force --copy || exit 1 intltoolize --force --copy --automake || exit 1 set +x This works with epiphany's build system (though it doesn't use gtkdocize). I also suspect it's wrong to use both glib-gettextize and intltoolize in autogen.sh, but I don't pretend to understand these tools Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Mon, 2015-06-22 at 10:44 -0500, Michael Catanzaro wrote: On Mon, 2015-06-22 at 16:36 +0100, Philip Withnall wrote: Do we require automake 1.13 though? Looks like it was released January 1, 2013... so we should. We *could*; doesn’t necessarily mean we *should*. Automake 2.0 isn’t out yet (though it looks cool), so I’d be tempted to leave in the ACLOCAL_AMFLAGS recommendation for backwards compatibility until automake 2.0 is released, and then bump everyone’s dependency to automake 1.13 and drop use of ACLOCAL_AMFLAGS. Unless you think automake 2.0 is being released imminently, and we should instead be adding a hard dependency on automake 1.13 and using AC_CONFIG_MACRO_DIRS to begin with? Automake 2.0 is supposed to be released later this year, and automake 1.13 has been around for a while, so I would definitely go straight to AC_CONFIG_MACRO_DIRS. As Kalev says, we should ensure this still builds with various distros. RHEL7 is fine. Debian stable (Jessie) has 1.14. Fedora has had ≥ 1.13 for a long time. Arch has 1.15. FreeBSD has 1.15. So unless anybody objects, I think a hard dependency on automake 1.13 would be fine. Would you mind updating the wiki page to match your suggestions? Probably also makes sense to update https://wiki.gnome.org/Initiatives/GnomeGoals/ModernAutotools which is a separate, though related, goal. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
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? As I understand it, autoreconf doesn’t know about running glib-gettextize, gtkdocize or intltoolize. 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 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=showredirect=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
Re: Death of gnome-common
On Sun, 2015-06-21 at 19:54 -0500, Michael Catanzaro wrote: OK, next problem. The porting guide says: Firstly, add AC_CONFIG_MACRO_DIR([m4]) to your configure.ac, and ACLOCAL_AMFLAGS = --install -I m4 ${ACLOCAL_FLAGS} to your top-level Makefile.am, regardless of which of the two options you choose below. But I see in Automake's NEWS file: - The ACLOCAL_AMFLAGS special make variable will be fully deprecated in Automake 2.0: it will raise warnings in the obsolete category (but still no hard error of course, for compatibilities with the many, many packages that still relies on that variable). You are advised to start relying on the new Automake support for AC_CONFIG_MACRO_DIRS instead (which was introduced in Automake 1.13). Do we require automake 1.13 though? Automake 2.0 isn’t out yet (though it looks cool), so I’d be tempted to leave in the ACLOCAL_AMFLAGS recommendation for backwards compatibility until automake 2.0 is released, and then bump everyone’s dependency to automake 1.13 and drop use of ACLOCAL_AMFLAGS. Unless you think automake 2.0 is being released imminently, and we should instead be adding a hard dependency on automake 1.13 and using AC_CONFIG_MACRO_DIRS to begin with? Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On 06/22/2015 05:44 PM, Michael Catanzaro wrote: On Mon, 2015-06-22 at 16:36 +0100, Philip Withnall wrote: Do we require automake 1.13 though? Looks like it was released January 1, 2013... so we should. Automake 2.0 isn’t out yet (though it looks cool), so I’d be tempted to leave in the ACLOCAL_AMFLAGS recommendation for backwards compatibility until automake 2.0 is released, and then bump everyone’s dependency to automake 1.13 and drop use of ACLOCAL_AMFLAGS. Unless you think automake 2.0 is being released imminently, and we should instead be adding a hard dependency on automake 1.13 and using AC_CONFIG_MACRO_DIRS to begin with? Automake 2.0 is supposed to be released later this year, and automake 1.13 has been around for a while, so I would definitely go straight to AC_CONFIG_MACRO_DIRS. I would personally like to keep GNOME git building with the toolchain that's in RHEL 7. It's automake 1.13.4 there though, so no problem with making it a hard dep :) -- Kalev ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
On Mon, 2015-06-22 at 16:36 +0100, Philip Withnall wrote: Do we require automake 1.13 though? Looks like it was released January 1, 2013... so we should. Automake 2.0 isn’t out yet (though it looks cool), so I’d be tempted to leave in the ACLOCAL_AMFLAGS recommendation for backwards compatibility until automake 2.0 is released, and then bump everyone’s dependency to automake 1.13 and drop use of ACLOCAL_AMFLAGS. Unless you think automake 2.0 is being released imminently, and we should instead be adding a hard dependency on automake 1.13 and using AC_CONFIG_MACRO_DIRS to begin with? Automake 2.0 is supposed to be released later this year, and automake 1.13 has been around for a while, so I would definitely go straight to AC_CONFIG_MACRO_DIRS. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
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 $@ 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.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/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?a ction=showredirect=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
Re: Death of gnome-common
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. 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.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/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=showredirect=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
Re: Death of gnome-common
On Sat, 2015-05-30 at 08:09 -0500, Michael Catanzaro wrote: This is a nit, but I think the 'set -x' to 'set +x' at the end of the sample autogen.sh is too expansive, since it results in the conditional tests being printed as independent statements: Good nit. Please feel free to update the wiki page. :-) Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
This is a nit, but I think the 'set -x' to 'set +x' at the end of the sample autogen.sh is too expansive, since it results in the conditional tests being printed as independent statements: autoreconf: Leaving directory `.' + '[' '' = '' ']' + ./configure --prefix /home/mcatanzaro/jhbuild/install --disable -static --disable-gtk-doc --disable-Werror I would probably move the 'set +x' up to after running autoreconf, perhaps with another pair around configure: set -x aclocal --install || exit 1 intltoolize --force --copy --automake || exit 1 autoreconf --verbose --force --install -Wno-portability || exit 1 set +x if [ $NOCONFIGURE = ]; then set -x $srcdir/configure $@ || exit 1 set +x ... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
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=showredirect=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
Re: Death of gnome-common
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=showredirect=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 signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Death of gnome-common
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). 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.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/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=showredirect=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]:
Re: Death of gnome-common
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/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=showredirect=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 -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org