Menu
▾
▴
[Plplot-cvs] SF.net SVN: plplot:[12780] trunk/cmake/build_projects
|
From: <ai...@us...> - 2013-11-29 21:51:17
|
Revision: 12780
http://sourceforge.net/p/plplot/code/12780
Author: airwin
Date: 2013-11-29 21:51:12 +0000 (Fri, 29 Nov 2013)
Log Message:
-----------
Split README into a "README" file that is just for users of epa_build
and where the directions are considerably simplified by referring to
files to edit and source in the setup directory, and README.developers
which is strictly for developers of epa_build.
Modified Paths:
--------------
trunk/cmake/build_projects/README
Added Paths:
-----------
trunk/cmake/build_projects/README.developers
Modified: trunk/cmake/build_projects/README
===================================================================
--- trunk/cmake/build_projects/README 2013-11-29 20:56:03 UTC (rev 12779)
+++ trunk/cmake/build_projects/README 2013-11-29 21:51:12 UTC (rev 12780)
@@ -1,13 +1,20 @@
-The build_projects project should work out of the box for
-Linux or Mac OS X systems with a full development tool-chain installed.
+This file contains directions for epa_build users. If in addition you
+are interested in helping to develop that project, you should look at
+README.developers as well.
+The epa_build project should work out of the box for Linux or Mac OS X
+systems with a full development tool-chain installed including
+relevant compilers (gcc, g++, gfortran, Ada in the suite of gcc
+compilers), relevant scripting languages (Python, Lua, etc.), make,
+and cmake (at least version 2.8.11.2).
+
But the situation is different on Windows where you have to download
and install specific toolchain software before you start.
===============================================================================
Installing the Required Windows Toolchain:
-N.B. There is a good possibility that build_projects will work with the
+N.B. There is a good possibility that epa_build will work with the
Microsoft proprietary toolchain, and I would be happy to accept
patches to make that so (including a patch for this file), but my only
experience is with free software so until I receive such patches, the
@@ -33,7 +40,7 @@
This downgrade is necessary and quite important, see
http://sourceforge.net/p/mingw/bugs/1950. Otherwise, you
will get an infinite hang from any attempt to do parallel
-builds (which build_projects automatically uses for many
+builds (which epa_build automatically uses for many
of its builds) using the MSYS make.exe command.
3. Install additional needed MSYS software that is not installed by
@@ -41,237 +48,114 @@
mingw-get.exe --recursive install msys-unzip
-4. Copy the MinGW-4.7.2/msys/1.0/bin directory to
+4. Download a recent cmake.exe version from
+http://www.cmake.org/files. I am currently using
+v2.8/cmake-2.8.10.2-win32-x86.zip. Unpack this using the unzip
+command you just installed and put cmake.exe on your PATH.
+
+5. [OPTIONAL] Copy the MinGW-4.7.2/msys/1.0/bin directory to
MinGW-4.7.2/msys/1.0/bin_without_sh and remove sh.exe from that latter
-PATH (This works around a CMake issue with the "MinGW Makefiles" generator.)
+PATH (This works around an issue with the "MinGW Makefiles" generator
+which apparently processes path names differently if sh.exe is in the
+PATH. Hopefully, that "MinGW Makefiles" kludge will disappear in the
+future.)
-5. Put both MinGW-4.7.2/bin and either MinGW-4.7.2/msys/1.0/bin (for
+6. Put both MinGW-4.7.2/bin and either MinGW-4.7.2/msys/1.0/bin (for
any Windows CMake generator you are going to use other than "MinGW
-Makefiles) or MinGW-4.7.2/msys/1.0/bin_without_sh (for the case of
-"MinGW Makefiles" on your PATH.
+Makefiles) or [OPTIONAL] MinGW-4.7.2/msys/1.0/bin_without_sh (for the case of
+"MinGW Makefiles") on your PATH.
-6. Download a recent cmake.exe version from
-http://www.cmake.org/files. I am currently using
-v2.8/cmake-2.8.10.2-win32-x86.zip. Unpack this using the unzip
-command you just installed. Put the resulting
-cmake-2.8.10.2-win32-x86/bin on your PATH. This downloadable binary
-(which poses a security concern like all downloadable binaries)
-is only used once.
+7. [OPTIONAL} If you are going to try the "NMake Makefiles JOM"
+generator, download the latest jom_VERSION.zip from
+http://releases.qt-project.org/jom, unpack it with unzip.exe just just
+installed and put jom.exe on your PATH.
-7. If you are going to try the "NMake Makefiles JOM" generator, download
-the latest jom_VERSION.zip from http://releases.qt-project.org/jom, unpack
-it with unzip.exe just just installed and put jom.exe on your PATH.
-
-8. If you are going to try the "Ninja" generator, then follow the
-build instructions for that tool at
+8. [OPTIONAL] If you are going to try the "Ninja" generator, then
+follow the build instructions for that tool at
http://www.cmake.org/pipermail/cmake/2013-June/055038.html + one
correction in a following post in that thread.
+
===============================================================================
+Set up instructions for epa_build
-Build instructions for the buildtools (such as cmake):
+1. Linux or Mac OS X.
-Note that when cmake is built this way it is configured by the
-bootstrap script (which demands sh is on the PATH) rather than cmake
-itself so the downloaded binary version of cmake used to configure the
-build_tools build is not actually used to build cmake which provides a
-slight increase in security for the paranoid. And you should be
-paranoid about security (i.e., you should build your own
-version of CMake from source, in my opinion rather than relying
-on a downloaded binary) since crackers are always
-trying it on.
+Tailor the indicated values in setup/setup_linux for your own
+system, then source that file, e.g.,
-Note the special paths below which have a _buildtools suffix, and also
-note the special option -DBUILD_THE_BUILDTOOLS=ON which configures
-builds of _only_ the build tools such as cmake that are used for the
-other software projects.
+source <Top directory of PLplot source tree>/cmake/epa_build/setup/setup_linux
-Linux "Unix Makefiles"
+2. Windows platforms
-wine@raven> mkdir -p /home/wine/newstart/build_script/build_dir-linux_buildtools
-wine@raven> cd /home/wine/newstart/build_script/build_dir-linux_buildtools
-wine@raven> rm -rf /home/wine/newstart/build_script/build_dir-linux_buildtools/*
-wine@raven> cmake -G"Unix Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/wine/newstart/build_script/install-linux_buildtools -DBUILD_THE_BUILDTOOLS=ON ~software/plplot_svn/HEAD/plplot_allura/cmake/build_projects >& cmake.out
-wine@raven> make VERBOSE=1 build_all >& build_all.out
+Similar instructions about tailoring and sourcing relevant files to be
+done later after I update and test the files in question.
-Windows "MSYS Makefiles" (This is a special case that requires sh.exe to
-be on the PATH so the "MinGW Makefiles" generator cannot be used.
+===============================================================================
+Build directions for epa_build
-bash.exe-3.1$ mkdir -p /z/home/wine/newstart/build_script/build_dir-git_buildtools
-bash.exe-3.1$ cd /z/home/wine/newstart/build_script/build_dir-git_buildtools
-bash.exe-3.1$ rm -rf /z/home/wine/newstart/build_script/build_dir-git_buildtools/*
-bash.exe-3.1$ cmake -G"MSYS Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/z/home/wine/newstart/build_script/install-git_buildtools -DBUILD_THE_BUILDTOOLS=ON /z/home/software/plplot_svn/HEAD/plplot_allura/cmake/build_projects >& cmake.out
-bash.exe-3.1$ mingw32-make.exe VERBOSE=1 build_all >& build_all.out
+1. Linux
-Build instructions for everything else which is not a build tool but
-which uses those (such as cmake) which have been built above:
+Note that setup_linux sets up all the important environment variables you
+need including GENERATOR_STRING, INSTALL_PREFIX, and BUILD_PROJECTS_SOURCE_PATH.
-1. Put the bin directory contained in the install tree created above
-at the top of the PATH. In my case this directory is either
-/home/wine/newstart/build_script/install-linux_buildtools/bin (Linux)
-or /z/home/wine/newstart/build_script/install-git_buildtool/bin
-(Windows). This step insures you will be using the buildtools you
-built yourself from source from now on rather than some downloaded binary.
+A. [OPTIONAL] build necessary additional buildtools whose versions you
+prefer compared to the versions available on your Linux distro.
-2. Adjust the local path to the PLplot source tree in plplot/bp.cmake
-(this will only be necessary until build_projects is updated to configure
-a build of an svn client that works on Windows). The alternative is
-to download and test a released version of PLplot, but I prefer the
-svn trunk version because that is much more up to date.
+# Insure you start with an empty build tree and vacant install tree
+# Set <Build tree prefix> to any convenient directory under your control
+# where you would like build results to be collected.
+mkdir -p <Build tree prefix>/build_dir-linux_buildtools
+rm -rf <Build tree prefix>/build_dir-linux_buildtools/* ${INSTALL_PREFIX}_buildtools
+cd <Build tree prefix>/build_dir-linux_buildtools
-3. Examples of configuring a build and test of PLplot and some of its
-soft dependencies on several different systems with various generators
-and build tools. Adjust these for your own paths, and note the first
-three commands in each group are to insure you start with a clean
-build directory
+cmake -DCMAKE_VERBOSE_MAKEFILE=ON -G"$GENERATOR_STRING" -DCMAKE_INSTALL_PREFIX:PATH=${INSTALL_PREFIX}_buildtools -DBUILD_THE_BUILDTOOLS=ON $BUILD_PROJECTS_SOURCE_PATH >& cmake.out
-Linux "Unix Makefiles"
+# Check cmake.out for any errors
+less cmake.out
---------------
-# Source this file to setup a Linux build_packages build.
-# Put latest CMake on PATH
-PATH=/home/software/cmake/install/bin:$PATH
+# Figure out which buildtools you want to build
+make help
-# Put buildtools that have been built and installed by build_packages on PATH.
-PATH=/home/wine/newstart/build_script/install-linux_buildtools/bin:$PATH
+# I recommend building all of them on Linux.
+make all >& all.out
-# Put Linux install directory on PATH (so that, e.g., the wxwidgets
-# configuration tool will be found.
-PATH=/home/wine/newstart/build_script/install-linux/bin:$PATH
+# Check all.out for any errors
+less all.out
-# Make *.pc files that are installed by a build_packages build accessible to
-# pkg-config
-export PKG_CONFIG_PATH=/home/wine/newstart/build_script/install-linux/lib/pkgconfig/:/home/wine/newstart/build_script/install-linux/share/pkgconfig
+B. Build and test a lite version of PLplot (without building or using
+major soft dependencies such as pango/cairo, Qt4, and wxwidgets)
+and [OPTIONAL] a fully configured PLplot version (where currently
+pango/cairo and wxwidgets are built and used and the system
+version of Qt4 is used).
-# As temporary measure also use system-installed *.pc files for dependencies
-# which are currently not built. Put these at the end of PKG_CONFIG_PATH
-# so they are only used as a last resort.
-PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/lib/x86_64-linux-gnu/pkgconfig:/usr/share/pkgconfig
---------------
+# Insure you start with an empty build tree and vacant install tree
+# Set <Build tree prefix> to any convenient directory under your control
+# where you would like build results to be collected.
+mkdir -p <Build tree prefix>/build_dir-linux
+rm -rf <Build tree prefix>/build_dir-linux/* ${INSTALL_PREFIX}
+cd <Build tree prefix>/build_dir-linux
-wine@raven> mkdir -p /home/wine/newstart/build_script/build_dir-linux
-wine@raven> cd /home/wine/newstart/build_script/build_dir-linux
-wine@raven> rm -rf /home/wine/newstart/build_script/build_dir-linux/*
-wine@raven> cmake -G"Unix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX:PATH=/home/wine/newstart/build_script/install-linux ~software/plplot_svn/HEAD/plplot_allura/cmake/build_projects >& cmake.out
-wine@raven> cmake -G"Unix Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/home/wine/newstart/build_script/install-linux ~software/plplot_svn/HEAD/plplot_allura/cmake/build_projects >& cmake.out
-# wxwidgets and pango are soft dependencies of PLplot which add value to
-# its build.
-wine@raven> make build_wxwidgets >& build_wxwidgets.out
-wine@raven> make build_pango >& build_pango.out
-# Build plplot using the above soft dependencies as well as some hard
-# dependencies it knows about.
-wine@raven> make build_plplot >& build_plplot.out
+cmake -DCMAKE_VERBOSE_MAKEFILE=ON -G"$GENERATOR_STRING" -DCMAKE_INSTALL_PREFIX:PATH=${INSTALL_PREFIX} $BUILD_PROJECTS_SOURCE_PATH >& cmake.out
-Windows "MinGW Makefiles"
+# Check cmake.out for any errors
+less cmake.out
-bash.exe-3.1$ mkdir -p /z/home/wine/newstart/build_script/build_dir-git_mingw
-bash.exe-3.1$ cd /z/home/wine/newstart/build_script/build_dir-git_mingw
-bash.exe-3.1$ rm -rf /z/home/wine/newstart/build_script/build_dir-git_mingw/*
-bash.exe-3.1$ cmake -G"MinGW Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/z/home/wine/newstart/build_script/install-git_mingw /z/home/software/plplot_svn/HEAD/plplot_allura/cmake/build_projects >& cmake.out
-bash.exe-3.1$ mingw32-make.exe VERBOSE=1 build_plplot >& build_plplot.out
+# Figure out which packages you want to build
+make help
-Other combinations that have been successfully tested in part by building
-all the C and C++ PLplot dependencies with the "build_all" target.
+# Build and test the "lite" version of PLplot
+make build_plplot_lite >& build_plplot_lite.out
-Note, the "build_all" target does not include PLplot itself yet
-(which has additional languages needs such as Fortran, and Ada which
-are known to not work for "Ninja" and which might not work for "NMake Makefiles JOM" ). Also note, we assume something similar to the first three commands
-given above has been used to start with a clean build tree.
+# Check build_plplot_lite.out for any errors
+less build_plplot_lite.out
-On Linux:
+# [OPTIONAL] Build and test the complete version of PLplot.
+make build_plplot >& build_plplot.out
-# "Ninja" generator
-irwin@raven> cmake -G"Ninja" -DCMAKE_INSTALL_PREFIX:PATH=/home/wine/newstart/build_script/install-linux_ninja ~software/plplot_svn/HEAD/plplot_allura/cmake/build_projects >& cmake.out
-irwin@raven> ninja -v build_all >& build_all.out
+# Check build_plplot.out for any errors
+less build_plplot.out
-On Windows:
+2. Windows platforms
-# "MSYS Makefiles" generator
-# This one should work for the build_plplot target as well, but I
-# haven't tested it yet.
-bash.exe-3.1$ cmake -G"MSYS Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/z/home/wine/newstart/build_script/install-git /z/home/software/plplot_svn/HEAD/plplot_allura/cmake/build_projects >& cmake.out
-bash.exe-3.1$ make.exe VERBOSE=1 build_all >& build_all.out
-
-# "Ninja" generator
-bash.exe-3.1$ cmake -G"Ninja" -DCMAKE_INSTALL_PREFIX:PATH=/z/home/wine/newstart/build_script/install-git_ninja /z/home/software/plplot_svn/HEAD/pl
-plot_allura/cmake/build_projects >& cmake.out
-bash.exe-3.1$ ninja -v build_all >& build_all.out
-
-# "NMake Makefiles JOM" generator
-# This CMake generator currently has some issues with using the MinGW suite
-# of compilers by default that must be worked around by being specific about
-# what compilers you want.
-bash.exe-3.1$ cmake -G"NMake Makefiles JOM" -DCMAKE_C_COMPILER:FILEPATH=/z/home/wine/newstart/MinGW-4.7.2/bin/gcc.exe -DCMAKE_CXX_COMPILER:FILEPATH=/z/home/wine/newstart/MinGW-4.7.2/bin/g++.exe -DCMAKE_RC_COMPILER:FILEPATH=/z/home/wine/newstart/MinGW-4.7.2/bin/windres.exe -DCMAKE_INSTALL_PREFIX:PATH=/z/home/wine/newstart/build_script/install-git_jom /z/home/software/plplot_svn/HEAD/plplot_allura/cmake/build_projects >& cmake.out
-bash.exe-3.1$ jom build_all >& build_all.out
-
-N.B. All of the above have been run without issues on a Wine platform
-(wine-git close to wine-1.6-rc1) and therefore should also work for
-the Microsoft version of Windows.
-
-===============================================================================
-Build configuration for the special case of GTK. The GNOME Tool Kit stack
-of libraries is normally built by jhbuild which keeps its configuration
-files in xml form. Here is how you convert that form of build-configuration
-data to the build_projects 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
-
-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
-
-# N.B. there are no plans to keep gtk_packages.xml, gtk_packages.rnc,
-# or pango_packages.data under version control. However, if a patch
-# is necessary for gtk_packages.xml created as above, we will keep
-# that patch under version control.
-
-# Finally to actually generate build configurations for build_packages run
-# the following command.
-
-cmake -DFILENAME:FILEPATH=pango_packages.data -P configure_bp.cmake
-
-# One known issue with the gtk+ stack is certain package dependencies
-# are completely missing such as pkg-config and libffi which have to
-# be built independently. For pkg-config we use a hand-generated
-# configuration, pkg-config/bp.cmake. Other missing packages that
-# can be configured with a template such as libffi, we use gtk_packages_add.xml
-# (under version control) as follows:
-
-rm -f add_packages.data
-touch add_packages.data
-PACKAGE_LIST="libffi intltool pixman gperf"
-for PACKAGE in $PACKAGE_LIST; do
- ./gtk_transform.py $PACKAGE 1 <gtk_packages_add.xml 1>> add_packages.data
-done
-cmake -DFILENAME:FILEPATH=add_packages.data -P configure_bp.cmake
+Very similar to above, but I will fill in variations that I used
+on Wine when I get a chance to test them again.
Added: trunk/cmake/build_projects/README.developers
===================================================================
--- trunk/cmake/build_projects/README.developers (rev 0)
+++ trunk/cmake/build_projects/README.developers 2013-11-29 21:51:12 UTC (rev 12780)
@@ -0,0 +1,76 @@
+This file contains directions for developers of the epa_build project.
+If you are only interested in using that project, you should be
+consulting the README file instead.
+
+The GNOME Tool Kit stack of libraries is normally built by jhbuild
+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
+
+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
+
+# N.B. there are no plans to keep gtk_packages.xml, gtk_packages.rnc,
+# or pango_packages.data under version control. However, if a patch
+# is necessary for gtk_packages.xml created as above, we will keep
+# that patch under version control.
+
+# Finally to actually generate build configurations for build_packages run
+# the following command.
+
+cmake -DFILENAME:FILEPATH=pango_packages.data -P configure_bp.cmake
+
+# One known issue with the gtk+ stack and other software we build is
+# certain package dependencies are completely missing 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:
+
+rm -f add_packages.data
+touch add_packages.data
+# 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"
+for PACKAGE in $PACKAGE_LIST; do
+ ./gtk_transform.py $PACKAGE 1 <add_packages.xml 1>> add_packages.data
+done
+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.
|
