Andrew Ross writes:
> Testing has shown that this is a result of a bug in gfortran versions <=
> 4.1 when both the fortran exit command and the instrinsic exit subroutine
> are used in the same program. I have committed a simple work-around in
> example 20 which should fix compilation for you. Could you check this?
Alan W. Irwin writes:
> However the fundamental cause there turned out to be due to a bug in the
> implementation of the VAX/VMS extension in an old version of gfortran
> which Andrew has now worked around (assuming Geoffrey verifies that
> workaround).
# Update my svn gateway
git-svn fetch
# Push all new revisions to my private "collaboration hub"
git push <my git collaboration hub repo> \*
cd <git working repo>
git fetch
# Update "topic" branch "trunk" which tracks "origin/svn/trunk"
git merge origin/svn/trunk
# Do fresh cmake with this script:
xiphi:t4/plplot/tmp | trunk cat ../run_cmake2
#!/bin/zsh
cmake -DCMAKE_INSTALL_PREFIX=$HOME/plplot/t4/install \
-DENABLE_tcl=ON -DENABLE_tk=on \
-DCMAKE_BUILD_TYPE=Debug \
-DBUILD_TEST=on \
-DENABLE_cxx=off -DENABLE_java=off -DENABLE_python=off \
-DHAVE_PTHREAD=off \
.. |& tee cmake.out
Results in this output:
...
Language Bindings:
ENABLE_f77: ON ENABLE_f95: ON
ENABLE_cxx: OFF ENABLE_java: OFF
ENABLE_python: OFF ENABLE_octave: OFF
ENABLE_tcl: ON ENABLE_itcl: OFF
ENABLE_tk: ON ENABLE_itk: OFF
ENABLE_pdl: OFF ENABLE_wxwidgets: OFF
ENABLE_gnome2: OFF ENABLE_pygcw: OFF
ENABLE_ada: OFF ENABLE_d: OFF
ENABLE_ocaml: OFF ENABLE_lua: OFF
...
And this build result:
...
Scanning dependencies of target x20f95
[ 59%] Building Fortran object examples/f95/CMakeFiles/x20f95.dir/x20f.f90.o
Linking Fortran executable x20f
[ 59%] Built target x20f95
Scanning dependencies of target x21f95
...
And the whole build completed without incident.
So, it looks fixed. Thanks Andrew, for the Fortran tweak, and Alan for the
other config and doc updates.
The git business does not have to be as long as shown above. A git master
repo would allow developers to pick up with the "git fetch". The preceding
material is relevant only for developers who are:
A) trying to track the master svn repo with git-svn, but who do *NOT* want to
work directly in their svn gateway git repo, but instead
B) want to push the revisions&branches obtained from svn into a "native git"
repo, and simulate that being the master, and
C) doing their actual work in a git working repo cloned from their "simulated
master git repo".
I've been making slow but steady progress on figuring out how to set up work
flows that ceneter around a developer having an "svn gateway repo"
(maintained with git-svn). From there you can either work in that repo, or
in some other git repo. There are reasons why people might choose either or
both of those options.
I haven't yet published a world-accessible git collaboration hub for PLplot,
but am working towards that, and will let people know when it's ready. And
I'm working on documenting how to do practice some work-flow scenarios that
make some sense to me.
More on all that as it crystalizes.
Good luck all with the release. I'm probably not going to be good for much
in the next few days due to other committments.
--
Geoff
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
