Created attachment 15412 [details]
gtkmm 2.2 spec file

Created attachment 15413 [details] [review]
Makefile patch to not build the examples directory

re. gtkmm 2.2.spec file: Please provide a patch, not a whole file, 
and not a file that is generated.
re. Makefile patch: This file is also generated. Providing a cvs 
patch will avoid this.

re Makefile patch: Furthermore, what does this have to do with the 
spec file and why would we want to do it?

When you do provide a patch please patch the ChangeLog.

Sorry, I'm reattaching my changes as a patch. It's against version
2.2.1 as I have no interest (or time at the moment) to track CVS gtkmm. 

Regarding the Makefile patch: the examples directory is not included
in SUBDIRS of any of the other gtkmm projects; it doesn't need to be
compiled for binary packages; it adds significantly to the compile
time; and, most importantly, it doesn't always compile (at least in
2.2.1), which breaks rebuilds. I strongly suggest not shipping release
versions of packages which won't build cleanly with a simple
./configure; make; make install.

Created attachment 15450 [details] [review]
new spec file, Makefile fix, and ChangeLog additions in patch format

> Regarding the Makefile patch: the examples directory is not included
> in SUBDIRS of any of the other gtkmm projects; 

It will be. If you look a the ChangeLog you'll see that this is a
recent change. Please don't change it back.

> it adds significantly to the compile
> time

Which isn't very relevant to the issue of rpms.

> and, most importantly, it doesn't always compile (at least in
> 2.2.1),

So report/fix the bugs.

> which breaks rebuilds. I strongly suggest not shipping release
> versions of packages which won't build cleanly with a simple
> ./configure; make; make install.

Again, fix/report bugs.

This can not be applied yet. The Makefile.am patch has nothing to do
with the rpm spec file. Also, you might consider using the version
number variables (e.g. of glib) from configure.in, like in the .pc.in
file. This would mean you don't have to keep changing the numbers
manually.

Are you likely to revise this patch?

> > it adds significantly to the compile
> > time
> 
> Which isn't very relevant to the issue of rpms.

True, but gtkmm takes long enough to compile as it is :) My main
complaint, however, is that it breaks the build. The time is not that
big of a deal.

> > and, most importantly, it doesn't always compile (at least in
> > 2.2.1),
> 
> So report/fix the bugs.

Usually I do. However, I don't track the development of gtkmm, nor am
I familiar with the API. I just package it because I use applications
that require it.

> This can not be applied yet. The Makefile.am patch has nothing to do 
> with the rpm spec file. Also, you might consider using the version
> number variables (e.g. of glib) from configure.in, like in the
> .pc.in file. This would mean you don't have to keep changing the 
> numbers manually.

I'll take out the Makefile.am patch since you said that building the
examples was intended. Just be warned that the examples in 2.2.1 don't
build cleanly (at least on my machine). I'll file a bug report when I
have a chance. Also, I'll look at using variables from configure.in.

> Are you likely to revise this patch?

Yeah. I've been busy at work with a project deadline. I'll send a new
patch once that passes.

>  My main
complaint, however, is that it breaks the build.

So please submit a bug. We can't fix it if you don't tell us.

I look forward to the new patch. Thanks.

Looks like Matthias picked up gtkmm2 at http://freshrpms.net/, so I'm
not going to package it myself anymore. I'm going to defer the spec
file to him since there's a better chance he'll be keeping it up-to-date.

I sent him an email. No reply so far. As ever, the .spec.in file is
for people who care about it to maintain. Nobody else is going to
worry about it.