[50947] trunk/dports/devel

Darren Weber dweber at macports.org
Thu May 14 13:02:35 PDT 2009


On Wed, May 13, 2009 at 5:05 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

> On May 13, 2009, at 18:22, dweber at macports.org wrote:
>
>  Revision: 50947
>>          http://trac.macports.org/changeset/50947
>> Author:   dweber at macports.org
>> 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:anonymous at public.kitware.com:/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.:

[ dweber at X ~/ports ]$ cswig
Cannot find SWIG Lib directory.  Checked:

/opt/local/var/macports/build/_Users_dweber_ports_devel_cableswig/work/cableswig-20090514/SWIG/Lib
[ dweber at X ~/ports ]$
[ dweber at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090514/615175f1/attachment.html>


More information about the macports-dev mailing list