[Plplot-cvs] SF.net SVN: plplot:[12799] trunk/cmake/epa_build

[<ai...@us...>]

Revision: 12799
          http://sourceforge.net/p/plplot/code/12799
Author:   airwin
Date:     2013-12-02 01:48:01 +0000 (Mon, 02 Dec 2013)
Log Message:
-----------
Update scripts for regenerating build configurations, and refer to
those scripts in the developer documentation rather than repeating
all the commands in those scripts.

Modified Paths:
--------------
    trunk/cmake/epa_build/README.developers
    trunk/cmake/epa_build/update_added_packages.sh
    trunk/cmake/epa_build/update_pango_packages.sh

Modified: trunk/cmake/epa_build/README.developers
===================================================================
--- trunk/cmake/epa_build/README.developers	2013-12-02 00:53:19 UTC (rev 12798)
+++ trunk/cmake/epa_build/README.developers	2013-12-02 01:48:01 UTC (rev 12799)
@@ -6,48 +6,17 @@
 which keeps its configuration files in xml form.  Here is how you
 convert that form of build-configuration data to the epa_build form.
 
-# Chose this latest version (as of August 2013) because it probably has
-# improved build and dependency instructions compared to previous versions.
-# For example, the glib version (2.37.4) is known to solve a build issue
-# that I ran into for earlier glib versions.
-export GTK_VERSION=3.9.4
-mkdir -p $GTK_VERSION
-cd $GTK_VERSION
-# This downloads all the relevant xml build configuration files
-# for the given version of GTK
-wget -nd  ftp://ftp.acc.umu.se/pub/GNOME/teams/releng/$GTK_VERSION/*
-cd ..
-./gtk_xml_recursive_process.py \
-$GTK_VERSION/gnome-apps-$GTK_VERSION.modules \
->| gtk_packages_$GTK_VERSION.xml
+# Download the jhbuild data for GTK_VERSION=3.9.4, collect all the
+# *.xml results into one giant xml file, "gtk_packages.xml", patch
+# that file, create a schema for that file, "gtk_packages.rnc" (not
+# used for anything but debugging of xml issues), convert that file to
+# a sequential form that can be read in by cmake called
+# "pango_packages.data", transform those data into build
+# configurations, */CMakeLists.txt, and patch those results.
+./update_pango_packages.sh
 
-# Patch this result to correct errors I have discovered in the jhbuild
-# configuration or else to use new versions of packages.
+Check for any errors:
 
-patch --no-backup-if-mismatch <patch_gtk_packages.xml
-
-# To create the schema for gtk_packages.xml use
-trang -I xml gtk_packages_$GTK_VERSION.xml gtk_packages_$GTK_VERSION.rnc
-
-# That resulting schema file is quite helpful in figuring out
-# how to process gtk_packages_$GTK_VERSION.xml as below.
-
-# Transform the xml form to a form that can be used by a cmake script.
-# Note, there will be some information messages sent to stderr by this
-# script that typically relate to good packages (ones that can be
-# transformed by this script) and bad packages. Currently the list of
-# bad packages are confined just to those which are completely missing
-# from the jhbuild data for gtk.  The first command-line argument is
-# the starting package name and the second command-line argument is a
-# control variable where the least significant bit is ON for following (hard)
-# "dependencies" dependencies, the next least significant bit is ON
-# for following (soft) "suggests", dependencies, and the next least
-# significant bit is ON for following (would be nice) "after"
-# dependencies.  Currently I use a command variable of 1 to keep
-# the number of packages configured for building pango and
-# (hard) dependencies to a minimum.
-./gtk_transform.py "pango" 1 <gtk_packages_$GTK_VERSION.xml 1>| pango_packages.data 2>|pango_packages.stderr
-
 # Check for errors:
 less  pango_packages.stderr
 
@@ -57,52 +26,29 @@
 # be configured another way).
 
 # N.B. there are no plans to keep gtk_packages.xml, gtk_packages.rnc,
-# or pango_packages.data under version control.  However,
+# or pango_packages.data under version control.  However, all
+# essential files referred to by update_pango_packages.sh such as
 # gtk_xml_recursive_process.py, patch_gtk_packages.xml, and
 # gtk_transform.py are all kept under version control so that
 # gtk_packages_$GTK_VERSION.xml, gtk_packages_$GTK_VERSION.rnc, and
 # pango_packages.data can be reproduced at any time for the current
-# $GTK_VERSION value or produced for some updated $GTK_VERSION value.
-# Note that in that latter case, it will be necessary to edit the file
-# names in patch_gtk_packages.xml to conform to the new version.
+# $GTK_VERSION value or produced for some updated $GTK_VERSION value
+# in the future.  Note that in that latter case, it will be necessary
+# to edit the file names in patch_gtk_packages.xml to conform to the
+# new version.
 
-# Finally to actually generate build configurations for build_packages run
-# the following command.
-
-cmake -DFILENAME:FILEPATH=pango_packages.data -P configure_epa.cmake
-
-# Patch generated configuration files.  This patch file contains
-# additional changes that cannot be done via a patch to the *.xml file.
-# Typically, these changes are hand edits which are tested then committed.
-# So typically the patch is created by rerunning the above cmake
-# command then using "svn diff" >| configured_pango.patch" to generate
-# the reverse form of the patch to change the result created by the
-# above cmake command into the svn committed form which is done with
-# the following patch command.
-
-patch --reverse --no-backup-if-mismatch -p0 <configured_pango.patch
-
-N.B. configured_pango.patch is kept under version control.
-
 # One known issue with the gtk+ stack and other software we build is
 # certain package dependencies are completely missing (called "bad
 # packages above) such as pkg-config and libffi which have to be built
 # independently.  For some of those missing packages we use a
-# hand-generated configuration (e.g., pkg-config/bp.cmake).  For
-# others that can be configured with a template (e.g., libffi) we use
-# add_packages.xml (under version control) as follows:
+# hand-generated configuration (e.g., pkg-config/CMakeLists.txt).  For
+# others that can be configured with a template (e.g., libffi) we add
+# additional configurations to add_packages.xml, process that file
+# with enough starting packages to include all dependent packages
+# in the resulting sequential file called "add_packages.data" which
+# is then processed to generated added build configurations such as libffi.
 
-rm -f add_packages.data add_packages.stderr
-touch add_packages.data add_packages.stderr
-# PACKAGE_LIST only contains the package names in add_packages.xml
-# that do not depend on any other package in that file.  Thus,
-# PACKAGE_LIST contains a list of "starting" packages and the
-# dependencies of those should suck in the rest of the packages in
-# add_packages.xml.
-PACKAGE_LIST="libffi intltool pixman gperf swig libxslt"
-for PACKAGE in $PACKAGE_LIST; do
-  ./gtk_transform.py $PACKAGE 1 <add_packages.xml 1>> add_packages.data 2>> add_packages.stderr
-done
+./update_added_packages.sh
 
 # Look for any bad results:
 less add_packages.stderr
@@ -110,6 +56,27 @@
 # It turns out there is one "bad" package, pkg-config which must be
 # configured with a hand-edited configuration.
 
-# Generate the "good" package configurations.
+# N.B. The build configurations generated by
+# "./update_pango_packages.sh" and "./update_added_packages.sh" are
+# committed under svn control so that care should be used to keep
+# everything consistent so that the above scripts introduce no svn
+# diffs.
 
+# Assuming no changes have been made to the essential files used by
+# "update_pango_packages.sh" (which are gtk_xml_recursive_process.py,
+# patch_gtk_packages.xml, and gtk_transform.py) to generate
+# pango_packages.data, then you can quickly check for such consistency
+# without running "./update_pango_packages.sh" using
+
+cmake -DFILENAME:FILEPATH=pango_packages.data -P configure_epa.cmake
+patch --reverse --no-backup-if-mismatch -p0 <configured_pango.patch
+svn diff
+
+# Similarly, assuming no changes have been made to the essential files
+# used by "update_added_packages.sh" (which are add_packages.xml and
+# gtk_transform.py) to generate add_packages.data, then you can
+# quickly check for such consistency without running
+# "./update_added_packages.sh" using
 cmake -DFILENAME:FILEPATH=add_packages.data -P configure_epa.cmake
+svn diff
+

Modified: trunk/cmake/epa_build/update_added_packages.sh
===================================================================
--- trunk/cmake/epa_build/update_added_packages.sh	2013-12-02 00:53:19 UTC (rev 12798)
+++ trunk/cmake/epa_build/update_added_packages.sh	2013-12-02 01:48:01 UTC (rev 12799)
@@ -1,12 +1,16 @@
 #!/bin/bash
 # Update build configurations of added packages that are described by
-# gtk_packages_add.xml
+# add_packages.xml
 
-rm -f add_packages.data
-touch add_packages.data
-# Ignore libxml2 since that is sucked in by the libxslt dependency.
-PACKAGE_LIST="libffi intltool pixman gperf libxslt ragel"
+rm -f add_packages.data add_packages.stderr
+touch add_packages.data add_packages.stderr
+# PACKAGE_LIST only contains the package names in add_packages.xml
+# that do not depend on any other package in that file.  Thus,
+# PACKAGE_LIST contains a list of "starting" packages and the
+# dependencies of those should suck in the rest of the packages in
+# add_packages.xml.
+PACKAGE_LIST="libffi intltool pixman gperf swig libxslt ragel"
 for PACKAGE in $PACKAGE_LIST; do
-  ./gtk_transform.py $PACKAGE 1 <gtk_packages_add.xml 1>> add_packages.data
+  ./gtk_transform.py $PACKAGE 1 <add_packages.xml 1>> add_packages.data 2>> add_packages.stderr
 done
-cmake -DFILENAME:FILEPATH=add_packages.data -P configure_bp.cmake
+cmake -DFILENAME:FILEPATH=add_packages.data -P configure_epa.cmake

Modified: trunk/cmake/epa_build/update_pango_packages.sh
===================================================================
--- trunk/cmake/epa_build/update_pango_packages.sh	2013-12-02 00:53:19 UTC (rev 12798)
+++ trunk/cmake/epa_build/update_pango_packages.sh	2013-12-02 01:48:01 UTC (rev 12799)
@@ -2,7 +2,11 @@
 # Update build configurations of pango packages that are described by
 # GTK+ jhbuild build configuration
 
-GTK_VERSION=3.9.4
+# Chose this latest version (as of August 2013) because it probably has
+# improved build and dependency instructions compared to previous versions.
+# For example, the glib version (2.37.4) is known to solve a build issue
+# that I ran into for earlier glib versions.
+export GTK_VERSION=3.9.4
 rm -rf $GTK_VERSION
 mkdir $GTK_VERSION
 cd $GTK_VERSION
@@ -12,10 +16,49 @@
 cd ..
 ./gtk_xml_recursive_process.py \
 $GTK_VERSION/gnome-apps-$GTK_VERSION.modules \
->|gtk_packages_$GTK_VERSION.xml_original
+>| gtk_packages_$GTK_VERSION.xml
+
 rm -rf $GTK_VERSION
-cp gtk_packages_$GTK_VERSION.xml_original gtk_packages_$GTK_VERSION.xml 
-patch --no-backup-if-mismatch gtk_packages_$GTK_VERSION.xml patch_gtk_packages.xml
 
-./gtk_transform.py pango 1 <gtk_packages_$GTK_VERSION.xml 1>| pango_packages.data
-cmake -DFILENAME:FILEPATH=pango_packages.data -P configure_bp.cmake
+# Patch this result to correct errors I have discovered in the jhbuild
+# configuration or else to use new versions of packages.
+
+patch --no-backup-if-mismatch <patch_gtk_packages.xml
+
+# To create the schema for gtk_packages.xml use
+trang -I xml gtk_packages_$GTK_VERSION.xml gtk_packages_$GTK_VERSION.rnc
+
+# That resulting schema file is quite helpful in figuring out
+# how to process gtk_packages_$GTK_VERSION.xml as below.
+
+# Transform the xml form to a form that can be used by a cmake script.
+# Note, there will be some information messages sent to stderr by this
+# script that typically relate to good packages (ones that can be
+# transformed by this script) and bad packages. Currently the list of
+# bad packages are confined just to those which are completely missing
+# from the jhbuild data for gtk.  The first command-line argument is
+# the starting package name and the second command-line argument is a
+# control variable where the least significant bit is ON for following (hard)
+# "dependencies" dependencies, the next least significant bit is ON
+# for following (soft) "suggests", dependencies, and the next least
+# significant bit is ON for following (would be nice) "after"
+# dependencies.  Currently I use a command variable of 1 to keep
+# the number of packages configured for building pango and
+# (hard) dependencies to a minimum.
+./gtk_transform.py "pango" 1 <gtk_packages_$GTK_VERSION.xml 1>| pango_packages.data 2>|pango_packages.stderr
+
+# Finally to actually generate build configurations for build_packages run
+# the following command.
+
+cmake -DFILENAME:FILEPATH=pango_packages.data -P configure_epa.cmake
+
+# Patch generated configuration files.  This patch file contains
+# additional changes that cannot be done via a patch to the *.xml file.
+# Typically, these changes are hand edits which are tested then committed.
+# So typically the patch is created by rerunning the above cmake
+# command then using "svn diff" >| configured_pango.patch" to generate
+# the reverse form of the patch to change the result created by the
+# above cmake command into the svn committed form which is done with
+# the following patch command.
+
+patch --reverse --no-backup-if-mismatch -p0 <configured_pango.patch

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.