#24100: sumo 0.11.1 : new port submission -----------------------------------------+---------------------------------- Reporter: guillaume-jean@… | Owner: ryandesign@… Type: submission | Status: closed Priority: Normal | Milestone: Component: ports | Version: 1.8.2 Resolution: fixed | Keywords: Port: sumo, sumo-devel | -----------------------------------------+---------------------------------- Changes (by ryandesign@…): * status: assigned => closed * resolution: => fixed Comment: Added sumo-devel in r68015. I restricted it to build a specific revision of the upstream source. It's not OK for a port to just build the latest upstream source available; it must use a specific version. I initially tried !r8773 (the latest version available today) but it wouldn't build. I tried !r8511 (the latest version available on 2010-03-24 when you submitted this ticket) but it had the same problem. In the end I used !r8004 (the revision when version 0.11.1 was tagged). This makes it kind of pointless to use the sumo-devel port at all; you'll get the same software as installing the sumo port. But it gives us a working port to start from. If you want to update sumo-devel to a later revision please file a new ticket and we can deal with it then. There was also a problem with sumo-devel fetching its sources from Subversion, namely that it checked out 214MB of stuff from the repository, of which 197MB was in the tests directory. Checking out this much data takes a very long time and is besides wasteful since the tests directory never gets used. (The 0.11.1 distfile doesn't even include the tests.) It does compress extremely well: a .tar.bz2 of the 214MB sumo directory comes to just 7MB. So one option would be to package up our own tarballs, host them in our own repository, and use those instead of checking out from their repository. But I find it a nuisance to package up and upload source tarballs, so instead I changed sumo-devel's fetch phase to have it check out everything from Subversion except the tests directory. This was a little more complicated to write, but means less work when updating the port later on. Normally I would discourage modifications to the fetch phase since the MacPorts built-in fetch phase handles everything nicely, except in this case it doesn't have the ability to exclude a directory from the checkout, so I had to write it myself. Instead of changing the configure.cmd to run "make -f Makefile.cvs" beforehand, I just used "use_autoreconf yes" since we already have that infrastructure available in MacPorts. I suppose this would be a problem if they change Makefile.cvs to do more than just run autoreconf, but that seems unlikely to me. -- Ticket URL: <http://trac.macports.org/ticket/24100#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS