Hi,
On Tuesday 20 July 2010 12:41:51 pm Stuart Henderson wrote:
> On 2010/07/20 12:12, Sebastian Reitenbach wrote:
> > Hi,
> >
> > On Tuesday 20 July 2010 09:21:53 am Landry Breuil wrote:
> > > On Tue, Jul 20, 2010 at 07:42:50AM +0200, Sebastian Reitenbach wrote:
> > > > Hi,
> > > >
> > > > On Monday 19 July 2010 09:35:14 pm Landry Breuil wrote:
> > > > > On Sun, Jul 18, 2010 at 07:34:54PM +0200, Sebastian Reitenbach 
wrote:
> > > > > > Hi,
> > > > > >
> > > > > > appended three new tcl/tk related ports. Since the last
> > > > > > submission a couple of weeks ago, more or less completely
> > > > > > reworked.
> > > > > >
> > > > > > graphics/tkimg:
> > > > > > This package enhances Tk, adding support for many
> > > > > > other Image formats: BMP, XBM, XPM, GIF (with
> > > > > > transparency, but without LZW), PNG, JPEG, TIFF.
> > > > >
> > > > > patch-Makefile_in looks wrong to me. what's that fucking up with
> > > > > fake dirs ? And what rm -r ${DESTDIR}/Img is doing in post-install
> > > > > ? that's a two-step install target ?
> > > >
> > > > I'll take a look at it again.
> > > >
> > > > > patch-XXX_configure should contain LIBfoo_VERSION (+ added to
> > > > > SUBST_VARS) to be cleaner... oh well. whatever. If there's only one
> > > > > SHLIB_VERSION.. forget about it :)
> > > > >
> > > > > -x-includes should use ${X11BASE}
> > > >
> > > > oops, I missed that.
> > > >
> > > > > replace that ugly sed+mv in post-install by a perl -pi construct
> > > > >
> > > > > why not trying to fix coccinella to work with png package instead
> > > > > of just disabling it ?
> > > >
> > > > Coccinella requires graphics/tkpng to start up. The graphics/tkimg is
> > > > for additional image formats that can be used with the whiteboard in
> > > > coccinella. the regression test in tkimg segfaults when it comes to
> > > > test the png stuff. Also when I try to startup coccinella with the
> > > > png package enabled it segfaults. I'll need to take a look again to
> > > > try
> > > > debugging/figuring out why it segfaults, I failed so far.
> > >
> > > ok, makes sense then - as long as there's a comment in Makefile :)
> >
> > appended a reworked tkimg tarball.
> > changes: * now using ${X11BASE} in the right place.
> >               * replaced sed/mv with perl -pi
> >               * comment in the makefile regarding the broken img::png
> > package * added a comment to the header of the patch-Makefile_in, why I
> > do the strange stuff in there (its indeed a two stage install) * remove
> > the ${DESTDIR}/Img not in the ports Makefile anymore, updated the
> > patch-Makefile_in to remove the dir in the install: stage
> >
> > I think that was all I did. Hope its better now. If there is a better way
> > to handle that two stage install, please let me know about it, or point
> > me to a port with a similar "problem"
> >
> > cheers,
> > Sebastian
>
> A couple of nits:
>
> This no longer pulls in pthread, so that can be removed
> from WANTLIB.
oh, my port-lib-depends-check doesn't warn me about the extra libs. But thats 
probably because of the installed threaded flavors of tcl/tk which also 
satisfy the BUILD/RUN depends.

>
> It wants something like REGRESS_DEPENDS=::${PKGPATH} as the tests
> don't run unless it's installed.
Oh, probably I always had it installed.

>
> And one other thing I'm not sure about, but I don't know how it
> should be handled, it may be that it's totally ok, or it may be
> that it's an unnecessary change..:
>
> -SHARED_LIB_SUFFIX='${TCL_TRIM_DOTS}\$\{DBGX\}.so'
> +SHARED_LIB_SUFFIX='${TCL_TRIM_DOTS}\$\{DBGX\}.so.${SHLIB_VERSION}'
>
> I don't have a good handle on the Tcl dlopen()d modules, is there
> anyone around who does who can say if this makes sense? For many
> ports, this sort of module doesn't get a version number..
I also checked and saw in devel/itcl, security/tcltls or x11/tktable that they 
have a version set. Which tcl/tk ports do not have a version on their shared 
libraries?

Tcl/Tk itself doesn't really care about the version number suffixing the .so 
in the library name. There can be multiple versions of the same 
library/extension next to each other. The loading first reads the pkgIndex.tcl 
file, there it defines which file to load for each version (those package 
ifneeded lines). The actual name of the shared library actually can be 
anything.

So when in a tcl script a line like:
package require foo 1.1
Then tcl starts searching its include path, for a pkgIndex.tcl file which has 
corresponding "package ifneeded foo 1.1" line (there are some rules to pick 
the right version, in case there is only one found e.g. providing "package 
ifneeded foo 1.2") 

So in short, I don't think for TCL/Tk libraries, the SHLIB_VERSION is really 
needed. I only fiddled with them since some of the ports omit the version 
after the .so, some of the ports use different numbers than 0.0.

Now someone has a suggestion how to handle that consistently on all tcl/tk 
libraries/extensions?

cheers,
Sebastian

Reply via email to