Menu
▾
▴
plplot-cvs
|
From: <ai...@us...> - 2013-11-30 21:49:32
|
Revision: 12784
http://sourceforge.net/p/plplot/code/12784
Author: airwin
Date: 2013-11-30 21:49:28 +0000 (Sat, 30 Nov 2013)
Log Message:
-----------
Really create updated instructions for developers of epa_build. (Last
commit for updated instructions only contained part of the edits.)
Modified Paths:
--------------
trunk/cmake/epa_build/README.developers
Modified: trunk/cmake/epa_build/README.developers
===================================================================
--- trunk/cmake/epa_build/README.developers 2013-11-30 20:19:07 UTC (rev 12783)
+++ trunk/cmake/epa_build/README.developers 2013-11-30 21:49:28 UTC (rev 12784)
@@ -71,6 +71,19 @@
cmake -DFILENAME:FILEPATH=pango_packages.data -P configure_bp.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 -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
@@ -79,8 +92,8 @@
# others that can be configured with a template (e.g., libffi) we use
# add_packages.xml (under version control) as follows:
-rm -f add_packages.data
-touch add_packages.data
+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
@@ -88,6 +101,15 @@
# add_packages.xml.
PACKAGE_LIST="libffi intltool pixman gperf swig"
for PACKAGE in $PACKAGE_LIST; do
- ./gtk_transform.py $PACKAGE 1 <add_packages.xml 1>> add_packages.data
+ ./gtk_transform.py $PACKAGE 1 <add_packages.xml 1>> add_packages.data 2>> add_packages.stderr
done
+
+# Look for any bad results:
+less add_packages.stderr
+
+# It turns out there is one "bad" package, pkg-config which must be
+# configured with a hand-edited configuration.
+
+# Generate the "good" package configurations.
+
cmake -DFILENAME:FILEPATH=add_packages.data -P configure_bp.cmake
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ai...@us...> - 2013-12-01 02:01:54
|
Revision: 12786
http://sourceforge.net/p/plplot/code/12786
Author: airwin
Date: 2013-12-01 02:01:49 +0000 (Sun, 01 Dec 2013)
Log Message:
-----------
Add libxslt to list of packages to be configured.
Modified Paths:
--------------
trunk/cmake/epa_build/README.developers
Modified: trunk/cmake/epa_build/README.developers
===================================================================
--- trunk/cmake/epa_build/README.developers 2013-12-01 01:05:55 UTC (rev 12785)
+++ trunk/cmake/epa_build/README.developers 2013-12-01 02:01:49 UTC (rev 12786)
@@ -99,7 +99,7 @@
# 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"
+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
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ai...@us...> - 2013-12-01 08:27:44
|
Revision: 12792
http://sourceforge.net/p/plplot/code/12792
Author: airwin
Date: 2013-12-01 08:27:41 +0000 (Sun, 01 Dec 2013)
Log Message:
-----------
Tweak the directions for epa_build developers.
Modified Paths:
--------------
trunk/cmake/epa_build/README.developers
Modified: trunk/cmake/epa_build/README.developers
===================================================================
--- trunk/cmake/epa_build/README.developers 2013-12-01 08:26:52 UTC (rev 12791)
+++ trunk/cmake/epa_build/README.developers 2013-12-01 08:27:41 UTC (rev 12792)
@@ -24,7 +24,7 @@
# Patch this result to correct errors I have discovered in the jhbuild
# configuration or else to use new versions of packages.
-patch <patch_gtk_packages.xml
+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
@@ -75,12 +75,12 @@
# 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
+# 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 -p0 <configured_pango.patch
+patch --reverse --no-backup-if-mismatch -p0 <configured_pango.patch
N.B. configured_pango.patch is kept under version control.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ai...@us...> - 2014-02-11 23:26:30
|
Revision: 12996
http://sourceforge.net/p/plplot/code/12996
Author: airwin
Date: 2014-02-11 23:26:27 +0000 (Tue, 11 Feb 2014)
Log Message:
-----------
Add some comments about the way foward for development of epa_build.
Modified Paths:
--------------
trunk/cmake/epa_build/README.developers
Modified: trunk/cmake/epa_build/README.developers
===================================================================
--- trunk/cmake/epa_build/README.developers 2014-02-11 00:31:22 UTC (rev 12995)
+++ trunk/cmake/epa_build/README.developers 2014-02-11 23:26:27 UTC (rev 12996)
@@ -80,3 +80,34 @@
cmake -DFILENAME:FILEPATH=add_packages.data -P configure_epa.cmake
svn diff
+OTHER NOTES:
+
+The epa_build configurations are still missing for certain packages.
+For example, a build of a strong-enough version of cmake so that it
+can support "https" downloads (sometimes required by epa_build itself)
+requires that cmake not use its weak internal curl library and instead
+use a fully configured external curl library. So the cmake epa_build
+should be configured with an external libcurl epa_build dependency,
+but that dependency does not exist yet. So I plan to use the
+directions (actually for the mingw-w64 fork of MinGW rather than for
+MinGW itself) in
+<http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html> as a guide to
+create an epa_build configure for both libcurl and its openssl
+dependency. Note, that URL contains mingw-w64 build directions for a
+large number of free software packages so it may also be useful to
+solve some epa_build problems for some packages for the pango/cairo
+stack of libraries that currently have epa_build configuration
+problems for MinGW/MSYS.
+
+Also, it is becoming clear that many users are switching from the
+classical combination of MinGW and MSYS to the combination of
+mingw-w64 and MSYS2 (see <http://sourceforge.net/p/msys2/wiki/MSYS2
+installation/> for install directions for that newer version). Note
+that new platform cannot be currently tested on Wine because of
+<http://bugs.winehq.org/show_bug.cgi?id=35561> so my (AWI's)
+participation in such tests could only be indirect. Nevertheless, I
+would encourage such tests since apparently MSYS2 (a simplification of
+modern Cygwin) has fewer bugs and uses more up-to-date versions of
+software than the traditional MSYS (a simplification of ancient
+Cygwin).
+
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ai...@us...> - 2014-03-16 20:50:44
|
Revision: 13075
http://sourceforge.net/p/plplot/code/13075
Author: airwin
Date: 2014-03-16 20:50:39 +0000 (Sun, 16 Mar 2014)
Log Message:
-----------
Update developer instructions for epa_build to be consistent with
latest gtk+ results. Also, list the outstanding development issues
that need work.
Modified Paths:
--------------
trunk/cmake/epa_build/README.developers
Modified: trunk/cmake/epa_build/README.developers
===================================================================
--- trunk/cmake/epa_build/README.developers 2014-03-16 20:21:30 UTC (rev 13074)
+++ trunk/cmake/epa_build/README.developers 2014-03-16 20:50:39 UTC (rev 13075)
@@ -11,65 +11,76 @@
# 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
+# "gtk+_packages.data", transform those data into build
+# configurations, */CMakeLists.txt, and patch those results. The shell
+# script that implements all of this is run as follows:
-Check for any errors:
+./update_gtk+_packages.sh
-# Check for errors:
-less pango_packages.stderr
-
-# That file currently shows there are 10 "good"
-# packages (ones found as a result of the pango package dependency
-# chain) and 14 "bad" packages (ones not found this way which have to
-# 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, all
-# essential files referred to by update_pango_packages.sh such as
+# or gtk+_packages.data under version control. However, all
+# essential files referred to by update_gtk+_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+_packages.data can be reproduced at any time for the current
# $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.
-# 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/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.
+# Check for any errors in the above procedure:
+less gtk+_packages.stderr
+# That file currently shows there are 17 dependencies of gtk+ that are
+# found with good jhbuild configurations and 22 dependencies of gtk+
+# that are not found (because there are no jhbuild configurations for
+# them).
+
+# 10 of those "not found" packages are officially ignored as a matter of policy.
+# See configure_epa.cmake for the full list, and the reasons for the
+# policy.
+
+# Some of those "not found" packages (i.e., libjpeg, libpng, and libtiff)
+# still may require epa_build configurations, but for now we
+# are putting up with the CMake warnings about these missing packages
+# until we evaluate whether their lack compromises the
+# wxwidgets capabilities on Unix (wxwidgets is the only PLplot-related
+# package that depends on gtk+, and that dependency only occurs for
+# the Unix case).
+
+# The rest of the "not found" packages such as pkg-config and libffi have
+# epa_build configurations that have been independently implemented.
+# Some of those have hand-generated configurations (e.g.,
+# pkg-config/CMakeLists.txt).
+
+# Other "not found" packages have been configured with a template
+# (e.g., libffi). This is done by adding additional configurations to
+# add_packages.xml, processing 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. The shell script
+# that implements this is run as follows:
+
./update_added_packages.sh
# Look for any bad results:
less add_packages.stderr
-# It turns out there is one "bad" package, pkg-config which must be
-# configured with a hand-edited configuration.
-
# N.B. The build configurations generated by
-# "./update_pango_packages.sh" and "./update_added_packages.sh" are
+# "./update_gtk+_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,
+# "update_gtk+_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
+# gtk+_packages.data, then you can quickly check for such consistency
+# without running "./update_gtk+_packages.sh" using
-cmake -DFILENAME:FILEPATH=pango_packages.data -P configure_epa.cmake
-patch --reverse --no-backup-if-mismatch -p0 <configured_pango.patch
+cmake -DFILENAME:FILEPATH=gtk+_packages.data -P configure_epa.cmake
+patch --reverse --no-backup-if-mismatch -p0 <configured_gtk+.patch
svn diff
# Similarly, assuming no changes have been made to the essential files
@@ -82,7 +93,23 @@
OTHER NOTES:
-The epa_build configurations are still missing for certain packages.
+It is becoming clear that substantial numbers of users are
+beginning to switch from the classical combination of MinGW and MSYS
+to the more modern combination of mingw-w64 and MSYS2 (see
+<http://sourceforge.net/p/msys2/wiki/MSYS2 installation/> for install
+directions for that newer version). Note that new platform cannot be
+currently tested on Wine because of
+<http://bugs.winehq.org/show_bug.cgi?id=35561> so my (AWI's)
+participation in such tests could only be indirect. Nevertheless, I
+would encourage such tests for epa_build since apparently MSYS2 (a
+simplified fork of modern Cygwin) has fewer bugs and uses more
+up-to-date versions of software than the traditional MSYS (a
+simplified fork of ancient Cygwin).
+
+There are still a number of outstanding development issues for epa_build.
+Please consult with AWI if you wish to work on one or more of these.
+
+* The epa_build configurations are still missing for certain packages.
For example, a build of a strong-enough version of cmake so that it
can support "https" downloads (sometimes required by epa_build itself)
requires that cmake not use its weak internal curl library and instead
@@ -96,18 +123,50 @@
dependency. Note, that URL contains mingw-w64 build directions for a
large number of free software packages so it may also be useful to
solve some epa_build problems for some packages for the pango/cairo
-stack of libraries that currently have epa_build configuration
-problems for MinGW/MSYS.
+subset of the gtk+ stack of libraries that currently have epa_build
+configuration problems for MinGW/MSYS.
-Also, it is becoming clear that many users are switching from the
-classical combination of MinGW and MSYS to the combination of
-mingw-w64 and MSYS2 (see <http://sourceforge.net/p/msys2/wiki/MSYS2
-installation/> for install directions for that newer version). Note
-that new platform cannot be currently tested on Wine because of
-<http://bugs.winehq.org/show_bug.cgi?id=35561> so my (AWI's)
-participation in such tests could only be indirect. Nevertheless, I
-would encourage such tests since apparently MSYS2 (a simplification of
-modern Cygwin) has fewer bugs and uses more up-to-date versions of
-software than the traditional MSYS (a simplification of ancient
-Cygwin).
+* A qt5_lite epa_build configuration is planned which would enable
+me to test PLplot against Qt5 (see recent list discussions concerning
+Qt5).
+* The qt4_lite build works fine on Linux but has not yet been tested on
+Windows.
+
+* The gtk+ complete stack of libraries (only required on Unix to
+satisfy a wxwidgets Unix dependency) builds fine on Linux. Part of
+these good Linux build results are for the pango/cairo subset of the
+gtk+ stack which is necessary on all platforms to support the "cairo"
+PLplot device driver and the libLASi library (necessary to support the
+psttf PLplot device driver). Unfortunately, the pango/cairo subset of
+gtk+ appears to have a number of build issues on Wine. I suspect most
+of those issues are not due to Wine bugs so I expect they will show up
+on Microsoft Windows as soon as someone attempts a build of pango or
+plplot (as opposed to plplot_lite) on that platform.
+
+* Currently epa_build has only been tested on Windows using my
+(extraordinarily slow) MinGW/MSYS/Wine platform for the plplot_lite
+case. The Wine developers view any deviation from Microsoft Windows
+behaviour as a Wine bug. So since it is unlikely that I am by
+accident taking advantage of some Wine bug to make this work, it
+should be trivial (and more than an order of magnitude faster than the
+Wine case) to follow what I have done for the MinGW/MSYS/Microsoft
+Windows case _if_ the bash.exe environment variable approach I
+document in cmake/epa_build/README is religiously followed. I also
+believe it should be straightforward to make the plplot_lite case work
+on the Cygwin platform, a mingw-w64/MSYS2 Windows platform, and a Windows
+platform consisting of the combination of MSYS (bash.exe and other
+MSYS tools are required for testing PLplot but will not be used for
+building it in this case) and MSVC. I have access to none of those
+platforms so volunteers are needed for this testing of epa_build for
+the plplot_lite case.
+
+* The epa_build of octave has not been configured. Octave has an
+enormous number of dependencies (much worse than PLplot), and I have
+no experience building octave. So I have decided to indefinitely put
+off working on this epa_build configuration. As a result, the octave
+component of the plplot epa_build is currently disabled both for
+plplot and plplot_lite, and it will likely be a long time before this
+limitation is removed unless someone else is motivated to
+make this work.
+
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X