cvs commit: ports/java/jgraphx Makefile distinfo

[Rob Farmer]

On Sun, Aug 29, 2010 at 3:23 AM, Chris Rees <utisoft at gmail.com> wrote:
> On 29 August 2010 01:11, Rob Farmer <rfarmer at predatorlabs.net> wrote:
>> On Sat, Aug 28, 2010 at 2:28 AM, Chris Rees <utisoft at gmail.com> wrote:
>>> 2010/8/27 Alexey Dokuchaev <danfe at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scilab-5.2.2_3.diff
Type: application/octet-stream
Size: 6183 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-ports/attachments/20100830/39ceeaca/scilab-5.2.2_3.obj