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: Closed FIXED
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-03-19 16:11 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.
Comment 13 Tobias Kortkamp freebsd_committer 2019-03-02 12:35:32 UTC
Ping.

(In reply to Lorenzo Salvadore from comment #12)
> 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.

You still need to have USES=gmake.  I suggest reading up on BINARY_ALIAS in
the Porter's Handbook [1].  When you have BINARY_ALIAS=make=gmake you can
safely delete this part of patch-Makefile:

X@@ -279,11 +278,11 @@ develDocPdf: bin/develDoc/
X 	rm -rf bin/develDoc/latexPdf bin/develDoc/warningLog
X 	cat doc/doxygen.conf doc/doxPdf|doxygen -
X 	cd bin/develDoc/latexPdf; for f in `ls *.eps`; do epstopdf $$f; done # Cygwin fix
X-	cd bin/develDoc/latexPdf/; make refman.pdf; mv refman.pdf ../develDoc.pdf
X+	cd bin/develDoc/latexPdf/; gmake refman.pdf; mv refman.pdf ../develDoc.pdf
X develDocPs: bin/develDoc/
X 	rm -rf bin/develDoc/latexPs bin/develDoc/warningLog
X 	cat doc/doxygen.conf doc/doxPs|doxygen -
X-	cd bin/develDoc/latexPs/; make refman.ps; mv refman.ps ../develDoc.ps
X+	cd bin/develDoc/latexPs/; gmake refman.ps; mv refman.ps ../develDoc.ps
X 

[1] https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/binary-alias.html
Comment 14 Tobias Kortkamp freebsd_committer 2019-03-02 12:42:07 UTC
(In reply to Tobias Kortkamp from comment #13)
You will also have to change all of the

cd ${WRKSRC} && ${MAKE_CMD} doc

to

cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${MAKE_CMD} doc

for this to work.  MAKE_ENV has PATH in it needed for BINARY_ALIAS to work.
It's a good idea to always pass through MAKE_ENV in general anyway since
the framework sets up various things through it.

To be even more correct use something like

cd ${WRKSRC} && ${DO_MAKE_BUILD} doc

or

${DO_MAKE_BUILD} -C ${WRKSRC} doc

This then also respects MAKE_ARGS, MAKE_FLAGS, etc.
Comment 15 commit-hook freebsd_committer 2019-03-19 16:04:31 UTC
A commit references this bug:

Author: swills
Date: Tue Mar 19 16:04:13 UTC 2019
New revision: 496268
URL: https://svnweb.freebsd.org/changeset/ports/496268

Log:
  math/frobby: create port

  Frobby is a software system and project for computations with monomial
  ideals. Frobby is free software and it is intended as a vehicle for
  computational and mathematical research on monomial ideals.

  The current functionality includes Euler characteristic, Hilbert
  series, maximal standard monomials, combinatorial optimization on
  monomial ideals, primary decomposition, irreducible decomposition,
  Alexander dual, associated primes, minimization and intersection of
  monomial ideals as well as the computation of Frobenius problems
  (using 4ti2) with very large numbers. Frobby is also able to translate
  between formats that can be used with several different computer
  systems, such as Macaulay 2, Monos, 4ti2, CoCoA4 and Singular. Thus
  Frobby can be used with any of those systems.

  WWW: http://www.broune.com/frobby/

  PR:		231208
  Submitted by:	Lorenzo Salvadore <phascolarctos@protonmail.ch>

Changes:
  head/math/Makefile
  head/math/frobby/
  head/math/frobby/Makefile
  head/math/frobby/distinfo
  head/math/frobby/files/
  head/math/frobby/files/patch-Makefile
  head/math/frobby/files/patch-src_HashMap.h
  head/math/frobby/files/patch-src_StatisticsStrategy.cpp
  head/math/frobby/files/patch-src_main.cpp
  head/math/frobby/files/patch-src_randomDataGenerators.cpp
  head/math/frobby/files/patch-test_runSplitTests
  head/math/frobby/files/patch-test_runTests
  head/math/frobby/pkg-descr
  head/math/frobby/pkg-help
  head/math/frobby/pkg-plist
Comment 16 Steve Wills freebsd_committer 2019-03-19 16:05:50 UTC
Committed, thanks, sorry it took so long.
Comment 17 Lorenzo Salvadore 2019-03-19 16:11:03 UTC
(In reply to Steve Wills from comment #16)

Thanks, but it was my fault if it took long: I was still working on the improvements suggested by the past comments. I will propose any new improvement in a new PR.

Thanks again.