reconfigure using autogen.sh for intltool 0.51 compatibility

[David Evans]

On 4/10/15 9:55 PM, Ryan Schmidt wrote:
>> On Apr 10, 2015, at 11:17 PM, devans at macports.org wrote:
>>
>> Revision
>> 134933
>> Author
>> devans at macports.org
>> Date
>> 2015-04-10 21:17:15 -0700 (Fri, 10 Apr 2015)
>> Log Message
>>
>> gimp2: reconfigure using autogen.sh for intltool 0.51 compatibility.
>> Modified Paths
>>
>> 	• trunk/dports/graphics/gimp2/Portfile
>> Added Paths
>>
>> 	• trunk/dports/graphics/gimp2/files/autogen.sh
> Just so I understand the fix, is it the case that you're adding autogen.sh to the files directory because this project doesn't ship with such a script itself?
>
> Is the autogen.sh you add the same for each project, or different? Where does the file come from?
>
>
>
Just to be clear:

The root problem is that a change (actually a fix for a long standing 
bug) was introduced in intltool 0.51 that
makes complimentary changes to BOTH intltool.m4 and po/Makefile.in.in in 
such a way that they have to
match.  If not, when intltool 0.51 is installed, a bogus locale path is 
generated which destroot flags as being outside the MacPorts mtree.

This requires that the port be reconfigured to replace both files prior 
to configure, typically using intltoolize.  Autoreconf is not sufficient 
because it does not run intltoolize.

Typically, intltoolize is run as part of autogen.sh in the process of 
creating the tarball from the repository code.  The autogen.sh file used 
is specific to the port in question.  Although many are similar, there 
is not one size that fits all. Some upstream developers are more 
creative than others.

Some ports distribute their autogen.sh file as part of the tarball but 
most do not thinking that is only necessary for use by the upstream 
maintainers.  Not in our case.

Finally, the upstream autogen.sh files sometime need to be modified for 
our use.  Typical changes include
   * add --force to intltool when not present to force it to replace an 
already existing po/Makefile.in.in
   * remove processing concerning repository processing that would fail 
in our case (doap files, .gitignore, etc).
   * any necessary processing that is done manually upstream outside of 
autogen.sh. (e.g. gimp2 has multiple po directories and intltoolize only 
fixes the basic po file, the rest need additional processing to replace 
their individual
Makefile.in.in files.)

So here's what I am doing:
  * if the autogen.sh file exists in the tarball, I use it, possibly 
with patches.
  * if not, I use a copy from the upstream repository, again possibly 
with modifications.

To anticipate a possible question, I do not automatically fetch the 
autogen.sh file from the repository because of
the additional complexity involved in the Portfile and the fact that 
these files do not change often (many have not
changed since they were first committed).  I add it to the files 
directory and install it in ${worksrcpath) in post-patch.
I considered using a PortGroup as well, but due to the customization 
that is involved with many of these ports, a blanket approach doesn't 
seem practical at this point.

These changes work with the existing intltool 0.50.2 as well as the 
newer 0.51 version and do not change the content of installed files 
(usually, see below)  so I am currently fixing ports that depend on 
intltool without any rebump.  In some cases, this involves fixing a port 
that didn't work in the first place.  Currently, I have fixed all the 
GNOME 3.16 ports in my GNOME-3/stable branch (not yet committed) and am 
working now on the non-GNOME ports.  As this involves over 100 ports and 
each port needs to be considered individually, it's taking a while.

When all the ports are fixed, the plan is as follows:
  * commit initltool 0.51 to trunk
  * commit the updated GNOME 3.16 ports most of which use intltool.
  * revbump any non GNOME 3.16 intltool dependents if necessary.

This last step recognizes the possible effect of the fix in intltool 
0.51.  Currently ports that depend on intltool do not always install 
their locale bits in the same path.   Some (older) ones install in 
${prefix}/lib/locale rather than ${prefix}/share/locale.  For ports that 
are not otherwise updated after the commit of intltool 0.51 and continue 
to display this problem, a revbump should take care of the problem.

End of lecture :-).  Questions, suggestions and most importantly, let me 
know if you can help with the remaining unmodified ports.

Dave