On Sun, Aug 29, 2010 at 3:23 AM, Chris Rees <utis...@gmail.com> wrote: > On 29 August 2010 01:11, Rob Farmer <rfar...@predatorlabs.net> wrote: >> On Sat, Aug 28, 2010 at 2:28 AM, Chris Rees <utis...@gmail.com> wrote: >>> 2010/8/27 Alexey Dokuchaev <da...@freebsd.org>: >>>> On Thu, Aug 26, 2010 at 09:53:32PM -0700, Rob Farmer wrote: >>>>> This breaks math/scilab (which is the only dependency in the ports >>>>> tree). Unfortunately, the author of jgraphx seems to completely >>>>> disregard backwards compatibility and changes the API in virtually >>>>> every release. >>>>> >>>>> I tried to patch Scilab based on their git repository (which has >>>>> support for 1.4.0.1), but hundreds of revisions have passed and they >>>>> have rearranged their tree a bit and added/removed some files, so it >>>>> didn't go well. >>>>> >>>>> IMHO, we need to either create a separate jgraphx-scilab port or keep >>>>> this in sync with Scilab (this is what Debian, Ubuntu, and Gentoo are >>>>> doing). >>>> >>>> Considering Scilab is the only consumer of jgraphx, it seems having >>>> special port would be an overkill. I think we should keep the two in >>>> sync, and probably work with upstream maintainers of both projects to >>>> improve compatibility and API inheritance in the future. Separate port >>>> of jgraphx-scilab is palliative solution, i.e. it simply increases the >>>> entropy, not solving the underlying problem. >>>> >>>> ./danfe >>> >>> >>> Since Scilab is the only consumer of jgraphx, I don't mind reverting it. >>> >>> Actually, I wrote that while trying to repair Scilab myself, so if you >>> want maintainership of jgraphx too, that's fine. >> >> I don't want to feel like I'm stealing your ports, but I do think it >> would be a good idea to have them maintained together. >> >>> >>> Alternatively you could have it as another distfile in Scilab rather >>> than depending on the port.... >> >> I hadn't thought about this, but it may actually be the best solution >> - as far as I'm aware, the reason for having libraries in separate >> ports is to allow multiple applications to use the same copy, but >> given the instability of the jgraphx API, I think it is unlikely that >> multiple ports could depend on one common version of jgraphx (at least >> without significant patching), so the benefits of having a jgraphx >> port are probably limited. Thoughts? >> > > You're not stealing my ports, you'd be taking a logical step to fixing > the madness! > > You are welcome to jgraphx if you want it, though having thought about > the instability, maybe the alternative distfile could be a good > solution. Have a look at the attached patch; the only thing i haven't > done is told configure it's not a problem that jgraphx.jar isn't there > yet... > > Of course, jgraphx is still a useful port for people who want to use > it themselves in their own programming; there are plenty of other > ports that aren't depended on by anything else! > > Chris >
It turns out that make extract unzips the jar file, so I fixed this and moved jgraphx inside the GUI option. I also added in the fix for PR 149659 to avoid having two PORTREVISION bumps in a short time. Plus, this became MAKE_JOBS_SAFE somewhere along the line. -- Rob Farmer
scilab-5.2.2_3.diff
Description: Binary data
_______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscr...@freebsd.org"