Bug 231208 - [NEW PORT] math/frobby: Software system and project for computations with monomial ideals
Summary: [NEW PORT] math/frobby: Software system and project for computations with mon...
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Steve Wills
URL:
Keywords:
Depends on:
Blocks: 231807
  Show dependency treegraph
 
Reported: 2018-09-06 20:40 UTC by Lorenzo Salvadore
Modified: 2019-02-08 12:24 UTC (History)
0 users

See Also:


Attachments
frobby shar file (102.52 KB, text/plain)
2018-09-06 20:40 UTC, Lorenzo Salvadore
no flags Details
frobby shar file - correction 1 (102.31 KB, text/plain)
2018-09-08 11:02 UTC, Lorenzo Salvadore
no flags Details
frobby shar file - correction 2 (102.31 KB, text/plain)
2018-09-08 16:33 UTC, Lorenzo Salvadore
no flags Details
frobby shar file - correction 3 (104.14 KB, text/plain)
2018-09-29 19:58 UTC, Lorenzo Salvadore
no flags Details
frobby shar file - correction 4 (104.12 KB, text/plain)
2018-09-30 10:14 UTC, Lorenzo Salvadore
no flags Details
frobby shar file - correction 5 (104.12 KB, text/plain)
2018-10-01 13:38 UTC, Lorenzo Salvadore
no flags Details
frobby shar file - correction 6 (104.10 KB, patch)
2019-02-08 12:24 UTC, Lorenzo Salvadore
phascolarctos: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Lorenzo Salvadore 2018-09-06 20:40:55 UTC
Created attachment 196928 [details]
frobby shar file

This port installs frobby executable, libfrobby.a static library and libfrobby.so shared library.

I am porting it because I am working at porting CoCoA, which has frobby as optional dependency.
Comment 1 Lorenzo Salvadore 2018-09-08 11:02:17 UTC
Created attachment 196957 [details]
frobby shar file - correction 1

The precedent shar file patched wrongly two files (#!/bin/bash was transformed in #!/usr/local/bin/bash irrespective of ${LOCALBASE}'s value).

This new shar file fixes the problem.
Comment 2 Lorenzo Salvadore 2018-09-08 16:33:45 UTC
Created attachment 196964 [details]
frobby shar file - correction 2

Sorry, had to correct this again: I had swapped the consequences of two options by mistake.
Comment 3 Lorenzo Salvadore 2018-09-08 20:37:12 UTC
Sorry, but I am founding other errors. Instead of submitting multiple corrections, I will test more extensively the port until I am more confident all errors have been solved.

Hence, please wait until the next shar file attachement to analyze this port.
Comment 4 Lorenzo Salvadore 2018-09-29 19:58:23 UTC
Created attachment 197607 [details]
frobby shar file - correction 3

Now it should works. It has been tested for linking in CoCoALib ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231807 ) build: the linking gives many errors (probably beceause the static library is badly designed by the author himself, if I understood correctly his work), but it works and the CoCoALib tests that verifies the linking with frobby are successful.
Comment 5 Lorenzo Salvadore 2018-09-30 10:14:40 UTC
Created attachment 197622 [details]
frobby shar file - correction 4

I have done some style corrections based on the suggestions I received on bug #231807.
Comment 6 Lorenzo Salvadore 2018-10-01 13:38:39 UTC
Created attachment 197673 [details]
frobby shar file - correction 5

More style corrections based on comments received on bug #231161.
Comment 7 Steve Wills freebsd_committer 2019-02-04 17:39:30 UTC
Can you explain why the shared library is disabled by default? Usually we try to avoid static linking when possible, while still providing the static lib for when it's needed.
Comment 8 Lorenzo Salvadore 2019-02-04 17:53:07 UTC
I choosed to include the static library only as default because I'm porting frobby as an optional dependency for CoCoA and CoCoALib (still working on them and other dependencies, I've been a bit busy unfortunately in the last months) and both of them link with the static library, but not with the shared library (developpers are uncomfortable with shared library).

Of course, I have no objection in including the shared library in the default package.
Comment 9 Steve Wills freebsd_committer 2019-02-04 18:15:11 UTC
(In reply to Lorenzo Salvadore from comment #8)
Ok, I would at least enable the shared library in frobby and if possible use it in anything that depends on it, rather than the shared lib.
Comment 10 Steve Wills freebsd_committer 2019-02-04 18:36:33 UTC
(In reply to Steve Wills from comment #9)
Can you go ahead and change the port so that the static lib, the shared lib and the executable are always built/installed and also replace the part of the patch that changes make to gmake with "BINARY_ALIAS=make=gmake"? I'll go ahead and test and commit the port after that.
Comment 11 Lorenzo Salvadore 2019-02-04 18:58:38 UTC
(In reply to Steve Wills from comment #10)

Sure, I will do it as soon as possible.

I'm surprised I cannot use USES=gmake. What's the reason?
Of course, I will add the build dependency together with the BINARY_ALIAS definition.
Comment 12 Lorenzo Salvadore 2019-02-08 12:24:50 UTC
Created attachment 201837 [details]
frobby shar file - correction 6

Here is the new shar file for frobby.

I put executable, static and shared options enabled by default as requested.

I was unable to rely on gmake through BINARY_ALIAS: I tried, adding the build dependency too, but something went wrong. Thus I left USES= gmake.
If you have some idea what I could have done wrong I will try again. Or if you can explain why BINARY_ALIAS= make=gmake is preferable to USES= gmake I could maybe propose an alternative solution.