Re: Integrate ITS Tool with gettext and Autotools (Was: Re: Death of gnome-common)

[Sébastien Wilmet]

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)

[Philip Chimento]

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)

[Alexandre Franke]

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.

-- 
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)

[Sébastien Wilmet]

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-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)

[Shaun McCance]

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)

[Philip Chimento]

On Fri, Oct 2, 2015 at 10:55 AM, Sébastien Wilmet  wrote:

> 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

[Javier Jardón]

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

[Sébastien Wilmet]

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

[Sébastien Wilmet]

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

[Michael Catanzaro]

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

[Michael Catanzaro]

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

[Michael Catanzaro]

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

[Philip Withnall]

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

[Daiki Ueno]

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

[Sébastien Wilmet]

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

[Sébastien Wilmet]

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

[Michael Catanzaro]

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

[Philip Withnall]

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

[Emmanuele Bassi]

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

[Philip Withnall]

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

[Michael Biebl]

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

[Michael Catanzaro]

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

[Michael Catanzaro]

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

[Philip Withnall]

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

[Emmanuele Bassi]

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

[Michael Catanzaro]

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

[Philip Withnall]

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

[Philip Chimento]

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

[Emmanuele Bassi]

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

[Michael Catanzaro]

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

[Philip Withnall]

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

[Philip Withnall]

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

[Philip Withnall]

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

[Kalev Lember]

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

[Michael Catanzaro]

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

[Philip Withnall]

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

[Jasper St. Pierre]

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

[Philip Withnall]

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

[Michael Catanzaro]

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

Death of gnome-common

[Philip Withnall]

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


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

[Daniel Mustieles García]

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

[Philip Withnall]

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

[Philip Withnall]

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

[Jasper St. Pierre]

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