#35869: Please Add HeapCL portfile --------------------------------+------------------------------------------- Reporter: ben@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: | Port: heapCL --------------------------------+------------------------------------------- Comment(by ben@…): Replying to [comment:3 ryandesign@…]:
Some remarks:
* You shouldn't use "system" just to create symlinks; MacPorts has an "ln" Tcl procedure for this. But even more importantly, why are you turning off the python portgroup's binary linking function, then doing it manually? On the assumption that you just don't want the binaries to be suffixed with the python version number, that's very simply accomplished: just write this line: {{{ python.link_binaries_suffix }}} * The upstream server only offers [wiki:PortfileRecipes#unversioned- distfiles unversioned distfiles] but you've got the port set up to fetch a versioned distfile. This succeeds because the upstream server is misconfigured; in fact you could request ''any'' version number of the heapCL distfile and you'd get the currently available one. Which means as soon as they do release a new version, users will start reporting checksum mismatches to you. You should advise the developers to offer standard immutable versioned distfiles like everybody else does.
Hi Ryan - Thanks for all your help! The server wasn't misconfigured, that was on purpose and specifically for mac ports. I found specifying the distfile directly resulted in it trying to change to a directory (on the local system) that doesn't exist. We *really* don't want to provide old versions of the software (and the portfile creation is something I added to the build process that creates all of the versions for the various platforms so they shouldn't be out of sync). Because (Heap|Torch)CL is a client that talks to the webservice API, old versions actually cause us to have to support older versions of the API for longer. In fact, we don't have version numbers, we have sha1 hashes (as our versions) -- the version numbers are entirely for mac ports (and if they install them manually, they update based on the hash). That said, I've placed a versioned file on the server for both products. I've also added a cleanup routine to delete all but the latest 3 versions, if you require more let me know. Now, to the linking thing. So I tried the built in method first, and bluntly it didn't work. So, I went and looked at how Google CL handled the problem. They did/do what I put in that file. That said, if you are saying that the linking is something new/fixed in the unified python group but was broken in python27 then I'll give it a shot. -- Ticket URL: <https://trac.macports.org/ticket/35869#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS