On Mon, 26 Jul 2004, Tim Jenness wrote:
> On Mon, 26 Jul 2004, Mark Taylor wrote:
>
> > I've just re-reached the stage of being able to build CCDPACK (why do
> > I feel like I'm wading through treacle?) hopefully with or without
> > itcl. In order to do this I've had to, amongst other things, back
> > out of the changes to configure.ac and Makefile.am that Brad made
> > 17 July to use the STAR_PATH_TCLTK macro.
>
> Hopefully not all the changes. You'll see that I switched to linking
> against the actual startcl libraries rather than the .o files. Couldn't
> understand why they exist when startcl goes to the effort of making
> libraries for exactly this purpose.
I can't understand either, but it does make the difference between
working and not working, at least for me. With the Makefile.am
that explicitly names the startcl .o files in libdir:
STARTCL_OBJ = $(libdir)/tkGwm.o $(libdir)/tkGwmCanv.o \
$(libdir)/tkGwmPrint.o $(libdir)/tclAdam.o
ccdwish builds and runs correctly. With the Makefile.am that
replaces this by
STARTCL_OBJ = -L$(libdir)/startcl -ltclAdam -ltkGwm
ccdwish builds, but running it just writes "Abort" and exits with an
error status (I think but am not sure it's a SIGABRT from somewhere).
I presume that startcl takes the unusual step of installing
the .o files into lib/ for a reason, and it may be connected with this,
though as I say don't have much idea what's really going on here.
> > I haven't investigated exactly what doesn't work right when
> > STAR_PATH_TCLTK is being used, except that it's probably down to
> > the idiosyncratic way that CCDPACK assembles the script files it
> > needs - if I was rewriting it from scratch it would probably do things
> > in a more standard way, but I'm not.
> >
> > Although STAR_PATH_TCLTK seems like it ought to be the way forward,
> > as I've mentioned before, CCDPACK has rather stringent requirements
> > on the TCL/TK setup it uses (this time not for historical reasons,
> > it requires some semi-private TCL include files), so in practice
> > I'm not sure it's worth getting it to look for a non-starlink
> > version of it, since it probably wouldn't work anyway.
> > For this reason I'd argue that the apparently retrograde step
> > of removing STAR_PATH_TCLTK again is a reasonable thing to do.
> >
>
> So ccdpack uses private tcl include files as well as private itcl include
> files??? :-)
yes it does: http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0407&L=stardev&T=0&F=&S=&P=14601
> Also, just out of curiosity, can you explain why all of the tcl/tk support
> tcl scripts are copied from the installed location to the build location?
> It seems that what's really happening is that ccdpack is creating an
> entirely new tcl/tk binary with an entire set of support libraries;
> presumably so that the directory can be moved around? Surely the support
> scripts will still be picked up from the standard location after the new
> binary is built?
Yes it's to be sure that it knows it can find all the support files
that it needs at run time. This means that it has no run-time
dependency on any external installation of tcl/tck/itcl.
I'd argue this is still a useful feature, but it dates from when
the CCDPACK *source* distribution held its own prebuilt wish binaries
for each of the supported target systems so it didn't even have
a build-time dependency on Tcl/Tk/iTcl.
> Since the standard tcl/tk now install these into share/tcl8.3/ and not
> lib/tcl8.2 that might account for one difficulty in the ccdpack build
> system.
Very likely.
> > Sorry to play ping pong, and I'm certainly not trying to discourage
> > people apart from me from tinkering with CCDPACK, but unless
> > I get an objection by tomorrow I will restore the CCDPACK
> > configure.ac and Makefile.am to their pre-STAR_PATH_TCLTK state.
> >
>
> As I said, can you leave in some of the tidy up we did?
> And also not have the hard-wired version number of TCL in the Makefile.am?
For the reasons above: I'm afraid mostly not. I've committed the working,
but untidy, versions. If you want to rejig it to use the libraries
rather than object files or whatever else then please do, as long as
it stays working afterwards (make sure ccdwish runs). Since we're
already some way over the amount of time we were supposed to spend
on this, I am reluctant to wade back into it for aesthetic reasons.
Sorry about that.
Mark
--
Mark Taylor Starlink Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|