From: Alan W. I. <ir...@be...> - 2002-11-30 02:42:24
|
I ask for your comments below on both the timing and implementation of merging the AT branch into CVS HEAD. But before getting to that here is the summary of where the AT project stands at the moment. Here is what works: (1) c, c++, f77, python, and tcl bindings and examples. (2) libltdl, the cross-platform dlopen wrapper (tested extensively on Linux and to a limited extent on Solaris). (3) dynamic xwin and ps drivers. (4) the distribution tarball approach (tested a few times on a rather software-challenged solaris machine). Here are the major categories of work left to do on this project with highest priority first: (1) tk binding. (2) the remainder of the dynamic drivers including tk and tkwin +++++++++++++++++++ (proposed date of merge, see below) (3) octave ******************* (conservative date for merge) (4) static drivers (5) deal with cross platform glitches. In planning the timing of the merge, I want to strike a reasonable balance between inconveniencing those working on MAIN HEAD, and the usual problem with branch development; rarely in a small group such as ours does anybody help out with branch development. From the solid achievements summarized above, the AT branch already passes the "nominally working" test similar to Geoffrey's judgement call when he decided to merge the dynamic driver changes into CVS HEAD. Thus, it would probably be reasonable to merge it now, but I am willing to wait to the "+++" line above when the next two things are done on the list above. The "+++" line above would only inconvenience Joao, I believe. Joao, do you mind doing the automake change for octave on CVS HEAD after the merge or do you want to do it on the AT branch before the merge? I will help as much as you like in either case. The "***" line corresponds to the most conservative time for the merge that I would like to adopt. Everything below that line does not work now on CVS HEAD so by definition nobody will be inconvenienced. In fact, I am convinced autotools will be a major convenience factor for our group's work in getting these two issues sorted out. I would like to adopt the "+++" time (which could conceivably be as early as Sunday if all goes well) for the merge if Joao positively agrees and there is also positive affirmation from at least either Geoffrey or Maurice (who I ask below to review the merge implementation). However, if there are any objections, then I will wait to merge until octave works on AT. I would now appreciate a review of the mechanics of the merge from the cvs guru's here (Maurice or Geoffrey) since I have never done a big merge like this before. So I hope you guys have access to your e-mail this weekend in the interests of getting the merge done soon. BTW, if there is any way to make this a more fail-safe procedure, please let me know! I definitely want to avoid flubbing up CVS head through some ill-advised cvs command. Here are the steps of what I propose at the time of the merge. (1) Tag cvs AT branch before merge using throwaway directory tree cvs checkout -r AT -d AT plplot cd AT cvs tag AT_1 cd .. (2) Tag cvs HEAD before merge using throwaway directory tree. cvs checkout -d plplot_b_ATmerge plplot cd plplot_b_ATmerge cvs tag b_ATmerge cd .. (3) do the merge (straight from the "merging an entire branch" section available with the "info cvs" command). First get MAIN HEAD with normal checkout then update the local copy with a merge. cvs checkout -d plplot plplot cd plplot # This only changes working directory cvs update -kk -j AT Question: would it be better to break this up by doing say the bindings directory, then the examples directory, then the overall directory? Can you break it up that way? (4) Check all is well with merged versions. In particular make sure no deleted files have come back to haunt us. Also, resolve conflicts. (5) Now change the repository, and after this commit we are all in business on CVS HEAD with the autotools approach! cvs commit -m "Merged AT into MAIN" Question: can this commit stage be done one sub-directory tree at a time if the answer to the previous question in (3) is yes? (6) I assume from my reading (but gurus please confirm) that the sticky tags (generated, e.g., by the -kk option above) only concern local directories and have nothing to do with the repository. So to get rid of them locally after the commit(s) are done is do a cvs update -a or a fresh checkout. Is that correct? Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
From: Joao C. <jc...@fe...> - 2002-11-30 16:24:56
|
On Saturday 30 November 2002 02:40, Alan W. Irwin wrote: > I ask for your comments below on both the timing and implementation of > merging the AT branch into CVS HEAD. But before getting to that here i= s > the summary of where the AT project stands at the moment. =2E.. > (3) octave > > ******************* (conservative date for merge) > > (4) static drivers > > (5) deal with cross platform glitches. =2E.. > The "+++" line above would only inconvenience Joao, I believe. Joao, d= o > you mind doing the automake change for octave on CVS HEAD after the mer= ge > or do you want to do it on the AT branch before the merge? I will help= as > much as you like in either case. I don't mind ( I prefer) doing it after the merge. But I tried to=20 configure/build AT without success. I followed your cookbook, with > autoconf --version autoconf (GNU Autoconf) 2.53 ( I compiled/installed 2.53 as the system's is 2.52) > automake --version automake (GNU automake) 1.5 > libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) I don't have any plplot environment variable set (even the infamous=20 LD_LIBRARY...) > cvs checkout -r AT -d AT plplot > cd AT > ./bootstrap.sh WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. /usr/bin/m4: configure.in: 352: Cannot open version.in: No such file = or directory Then, I > m4 --version GNU m4 1.4o > cp cf/version.in . And executed each of bootstrap.sh lines one by one: > aclocal > touch include/plConfig.h.in > libtoolize --copy --ltdl --automake > automake --add-missing No errors so far. Now, > autoheader WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. /usr/bin/m4: configure.in: 353: Non-numeric argument to built-in `div= ert' /usr/bin/m4: configure.in: 368: Non-numeric argument to built-in `div= ert' =2E.. /usr/bin/m4: sysloc.in: 58: Non-numeric argument to built-in `divert' /usr/bin/m4: sysloc.in: 916: Non-numeric argument to built-in `divert= ' =2E.. configure.in:570: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst =2E.. configure.in:742: warning: do not use m4_regexp: use regexp or m4_bre= gexp autoheader: missing template: PLPLOT_VERSION And finally, just for completion, > autoconf=20 > ./configure --prefix=3D/usr/local/plplot_at --with-double --enable-dynd= rivers No defaults file found, performing full configure. ./configure: =3D: command not found ./configure: 3 ----- =2E.. cat >>confdefs.h <<_ACEOF #define PLPLOT_VERSION 5.1.0 _ACEOF : No such file or directory ./configure: _ACEOF: command not found checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets ${MAKE}... yes checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output... configure: error: C compile= r cannot create executables So, what do you think I should do now? Joao |
From: Alan W. I. <ir...@be...> - 2002-11-30 21:24:55
|
On Sat, 30 Nov 2002, Joao Cardoso wrote: > On Saturday 30 November 2002 02:40, Alan W. Irwin wrote: > > I ask for your comments below on both the timing and implementation of > > merging the AT branch into CVS HEAD. But before getting to that here is > > the summary of where the AT project stands at the moment. > ... > > > (3) octave > > > > ******************* (conservative date for merge) > > > > (4) static drivers > > > > (5) deal with cross platform glitches. > ... > > > The "+++" line above would only inconvenience Joao, I believe. Joao, do > > you mind doing the automake change for octave on CVS HEAD after the merge > > or do you want to do it on the AT branch before the merge? I will help as > > much as you like in either case. > > I don't mind ( I prefer) doing it after the merge. Thanks, Joao. That simplifies the decision making. So the merge date now depends on my progress with tk and drivers (moving well), either Maurice or Geoffrey reviewing my proposed cvs commands for the big merge and finally solving the "2.53" problem you just found with the scripts called by bootstrap.sh (see below). > But I tried to > configure/build AT without success. Thanks very much for giving AT a try and thus finding the bootstrap.sh problems for your system. I have just committed a change which I believe will solve that problem. The commit message explains why 2.13 stuff got back into AT, but I believe I have eliminated it now. So please try it again, and let me know the results. By the way, I cannot detect 2.13 legacy stuff in AT because Debian still supports it in a legacy mode. From the description of the Debian autoconf package: "This version (2.53) of autoconf contains many changes from the previous release, version 2.13. For now, it depends on autoconf2.13 to provide compatibility. This will eventually go away, so please upgrade your autoconfiscations." So your help is essential is making sure AT is fine for a pure 2.53 system. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
From: Maurice L. <mj...@ga...> - 2002-12-01 02:26:56
|
Alan W. Irwin writes: > By the way, I cannot detect 2.13 legacy stuff in AT because Debian still > supports it in a legacy mode. > ... > So your help is essential is making sure AT is fine for a pure 2.53 system. I'm running a locally-installed version 2.54 in order to detect compatibility problems quickly. I may yet get to building AT this weekend but am tremendously busy so it may have to wait.. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Joao C. <jc...@fe...> - 2002-12-01 23:59:55
|
On Saturday 30 November 2002 21:23, Alan W. Irwin wrote: > On Sat, 30 Nov 2002, Joao Cardoso wrote: > > On Saturday 30 November 2002 02:40, Alan W. Irwin wrote: =2E.. > > > But I tried to > > configure/build AT without success. > > Thanks very much for giving AT a try and thus finding the bootstrap.sh > problems for your system. I have just committed a change which I belie= ve > will solve that problem. > > The commit message explains why 2.13 stuff got back into AT, but I beli= eve > I have eliminated it now. > > So please try it again, and let me know the results. It now configure/runs/installs OK. Also the x08c example compiles and run= s OK. Good job. The only problem is the need to install the package to run the demo. This= will=20 be handled latter, right? Otherwise developing will be a pain. Joao |
From: Alan W. I. <ir...@be...> - 2002-12-02 01:07:45
|
On Mon, 2 Dec 2002, Joao Cardoso wrote: > > It now configure/runs/installs OK. Also the x08c example compiles and runs OK. > Good job. That is a big relief to hear that most welcome news! My thanks to Maurice for dealing with this autoconf version issue ahead of time so the fix was essentially just a new copy of the file he worked on. I am still not completely done with all the driver issues so it will be late tonight or more probably early tomorrow when I do the merge. > > The only problem is the need to install the package to run the demo. I think the idea of having multiple install locations (which is essentially what we do now) is pretty much outside the autotools paradigm. However, we could go to the effort of symlinking everything to tmp and making a huge Makefile.am there which repeated all the build rules, and I think that would work. But right now "make install" is very fast so we may not want to go to this trouble. I think the thing to do is to gain some experience with this whole new paradigm over the next few months, then evaluate where we want to go from there. Alan |
From: Maurice L. <mj...@ga...> - 2002-12-01 02:39:27
|
Alan W. Irwin writes: > Here are the major categories of work left to do on this project > with highest priority first: > > (1) tk binding. > > (2) the remainder of the dynamic drivers including tk and tkwin > > +++++++++++++++++++ (proposed date of merge, see below) That would be fine with me. > Here are the steps of what I propose at the time of the merge. > ... Looking pretty good to me. > (3) do the merge (straight from the "merging an entire branch" section > available with the "info cvs" command). First get MAIN HEAD with normal > checkout then update the local copy with a merge. > > cvs checkout -d plplot plplot > cd plplot > # This only changes working directory > cvs update -kk -j AT > > Question: would it be better to break this up by doing say the bindings > directory, then the examples directory, then the overall directory? > Can you break it up that way? You could but I'd just do the whole thing all at once, capturing the output in its own window or file, which you'll need to refer to when resolving conflicts. Or you can always recover what files had conflicts by doing a 'cvs -nq update', one of my favorite commands. If the merge is done in a dir you don't want it, just remove the whole directory. Doing it all at once is simplest and removes the danger that you'll forget to do it somewhere. > Question: can this commit stage be done one sub-directory tree at a time > if the answer to the previous question in (3) is yes? Sure. > (6) I assume from my reading (but gurus please confirm) that the sticky tags > (generated, e.g., by the -kk option above) only concern local directories > and have nothing to do with the repository. So to get rid of them locally > after the commit(s) are done is do a > > cvs update -a > > or a fresh checkout. Is that correct? Correct. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2002-12-01 02:45:25
|
Maurice LeBrun writes: > Alan W. Irwin writes: > > Here are the steps of what I propose at the time of the merge. > > ... > > Looking pretty good to me. BTW I'm not sure how you managed the AT branch but be prepared for potentially lots of petty conflicts. It's not nearly as bad as it may look initially. If you ever merged the head back onto the branch, be prepared for lots of conflicts that ask you to choose between two basically identical sections of code. I recommend doing plenty of recursive diffs between an existing head and AT checkout (preferably both with -kk so you aren't bothered by $Id$ diffs) and the merged tree to see what's changed. Good luck.. :) -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-12-01 03:27:03
|
On Sat, 30 Nov 2002, Maurice LeBrun wrote: > Alan W. Irwin writes: > > Here are the major categories of work left to do on this project > > with highest priority first: > > > > (1) tk binding. > > > > (2) the remainder of the dynamic drivers including tk and tkwin > > > > +++++++++++++++++++ (proposed date of merge, see below) > > That would be fine with me. Great! And thanks very much for your helpful comments on my cvs merge plans. And now for the current AT status report: Today I made a lot of progress. (1) is done, and (2) is almost there (although not checked in yet). So the only real issue left is the autoconf version stuff. I am hoping the additional changes that I have already committed today will have sorted out (most if not all of) that remaining issue. Thus, one simple further test consisting of checking out the latest AT on a pure autoconf 2.5x system; running ./bootstrap.sh; and recording the error messages (if any) would be most helpful. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |