On 4/10/15 9:55 PM, Ryan Schmidt wrote:
On Apr 10, 2015, at 11:17 PM, [email protected] wrote:
Revision
134933
Author
[email protected]
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
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
