#29919: octave / octave-devel @3.4.2 updated portfile ---------------------------------------+------------------------------------ Reporter: lukas.reichlin@… | Owner: michaelld@… Type: update | Status: closed Priority: Normal | Milestone: Component: ports | Version: Resolution: fixed | Keywords: haspatch Port: octave-devel | ---------------------------------------+------------------------------------ Comment(by michaelld@…): Lots to answer! I'm glad you're keeping up with Octave, since I don't really have the time to. A) I agreed with your changes to remove the --with and --enable configure flags. Looking at the output of "./configure --help" shows that those flags are the defaults and thus aren't needed; or that they don't do anything. Good. B) The MacPorts configure options (e.g., "configure.perl") are still needed, since the 'configure' script picks up that provided by Apple instead (e.g., in /usr/bin ). I'd prefer to use known programs, and thus choose to use those provided by MacPorts. No drama though. C) I don't know if the licenses for Octave and any of its dependencies conflict. That's above my pay grade and IANAL. TINLA: I can say that MacPorts in and of itself does not violate licenses, since it is not immediately distributing tarballs (except its own) or binaries, and, TTBOMK, does not form a greater work with respect to any ports it might install. The burden really is on the end-user who is telling MacPorts to install various ports, for him/her to figure out how to deal with multiple, possibly conflicting, licenses if/when he/she decides to distribute some greater work. That said, the MacPorts project does try to provide variants such that it should be clear to the end-user whether licenses are possibly conflicting. See, e.g., 'port info ffmpeg'. D) If someone -really- wants to debug octave, they'll need to compile with -O0 to remove optimization including inlining, and add in debugging to the libraries via -g#. I pick -g3 for the max debugging info, supposed to be placed into the libraries such that one doesn't entirely need the original source code any longer (since it generally won't be around after MacPorts installs the port). Maybe there is a better way, but this worked for me once upon a time. Maybe octave has become stable enough that this variant is no longer necessary? 1) The default 'configure' script will always check for FLTK; if it finds fltk-config in the PATH, then it will try to use it, no matter any other configure options. The patch-configure file corrects this behavior and allows the use of a shell environment variable to completely disable fltk checking. While I could split this patch into 2 parts -- one for if doing +fltk and another if not -- it works either way and so I'm just leaving it as is until the Octave folks get around to augmenting their side. 2) Default to gnuplot: probably. Please feel free to figure out how to do this & submit another ticket with a patch. I don't have time to work this issue out, for many months down the road. 3) Don't know. Could be a while, since that would be a major change in MacPorts' various octave-dependent ports. I think this decision is above my pay grade. 4) OK; good to know about. I don't use Octave very often any longer, so I haven't kept up with these changes. -- Ticket URL: <https://trac.macports.org/ticket/29919#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS