On Wed, May 13, 2009 at 5:05 PM, Ryan Schmidt <[email protected]>wrote:
> On May 13, 2009, at 18:22, [email protected] wrote: > > Revision: 50947 >> http://trac.macports.org/changeset/50947 >> Author: [email protected] >> Date: 2009-05-13 16:22:30 -0700 (Wed, 13 May 2009) >> Log Message: >> ----------- >> new port for CableSwig >> >> Added Paths: >> ----------- >> trunk/dports/devel/cableswig/ >> trunk/dports/devel/cableswig/Portfile >> >> Added: trunk/dports/devel/cableswig/Portfile >> =================================================================== >> --- trunk/dports/devel/cableswig/Portfile >> (rev 0) >> +++ trunk/dports/devel/cableswig/Portfile 2009-05-13 23:22:30 UTC >> (rev 50947) >> @@ -0,0 +1,60 @@ >> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; >> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 >> +# $Id$ >> + >> +PortSystem 1.0 >> + >> +name cableswig >> +version cvs >> +# CableSwig is only available from cvs and there are no release tags >> > > [snip] > > +fetch.type cvs >> +cvs.root :pserver:[email protected]:/cvsroot/CableSwig >> +cvs.module CableSwig >> > > It looks like this port is downloading from cvs head, meaning if you > install the port today, and then some more development occurs, and I install > the port tomorrow, we have different versions of software installed on our > computers, though we installed the same "version" ("cvs") of the port. This > isn't how ports should work. Ports should install the same software on > everyone's computer. > > As Rainer said, you should restrict the date of the cvs checkout to some > specific date that you know to work properly. You can use that in the > "version" variable too. (So then "version" will be something like > "20090513".) > > I think you will then have to increase the epoch so that MacPorts knows > that your new version number is supposed to be treated as newer than the > string "cvs". If cableswig is not yet in the rsync release, can I just replace the svn with a new version and skip the epoch definition? How does this comparison work out? Do we actually get lucky with an upgrade in this case? version 20090514 vs version cvs_0 > > > > +configure { >> + xinstall -d -o root -g admin -m 0755 ${build.dir} >> > > Is it really necessary to make this directory as root? Some of us prefer > using MacPorts in a prefix that is not owned by root, and the above will > cause this port to fail for us. > I guess not. Seems to work without it, so it can go. > + system "cd ${build.dir} && cmake ${configure.args} ${worksrcpath}" >> +} >> + >> +configure.args \ >> + -DCMAKE_OSX_SYSROOT=${universal_sysroot} \ >> + -DCMAKE_BUILD_TYPE:STRING=Release \ >> + -DBUILD_SHARED_LIBS:BOOL=ON \ >> + -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \ >> + -DCMAKE_INSTALL_RPATH:STRING=${prefix}/lib/cableswig \ >> + -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \ >> + -DCMAKE_INCLUDE_PATH:PATH=${prefix}/include \ >> + -DCMAKE_LIBRARY_PATH:PATH=${prefix}/lib \ >> + -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \ >> + -DCSWIG_USE_SYSTEM_GCCXML:BOOL=ON >> > > Have you tried using the cmake portgroup yet? It should simplify ports that > use cmake to build. > I did consider it for vtk-devel, where it doesn't apply exactly. I figure it's clearer to define everything directly. It will avoid dependency on the port group, which could change at some point. There are some overlaps in this port and the port group (as it stands), but ... the dependency seems like just another layer of complexity for management (in my view). The configure is fairly simple in this port and it's all right there in front of me when it's all in the port (no need to lookup the port group or worry about it changing). The port group abstraction may be useful. Maybe I'll change my mind some day ;-) Best, Darren PS, There is an issue with this port for cableswig, i.e.: [ dwe...@x ~/ports ]$ cswig Cannot find SWIG Lib directory. Checked: /opt/local/var/macports/build/_Users_dweber_ports_devel_cableswig/work/cableswig-20090514/SWIG/Lib [ dwe...@x ~/ports ]$ [ dwe...@x ~/ports ]$ otool -L /opt/local/bin/cswig /opt/local/bin/cswig: /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3) I have no idea how to correct this, got to check back with the ITK crew on what's going on here. Good reason for a ticket on this one.
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
