not compatible with SPICE3f5.
- Remove bsd.prog.mk dependency.
- Put variables in ${FILESDIR}/FreeBSD* configuration file into
${FILES}/Makefile.
- Use opt_USE instead of .if ${PORT_OPTIONS:Mopt}.
- Remove unnecessary changes in patch-conf_defaults.
This port generates a makefile and then passes it to "make" via stdin,
which makes it different to troubleshoot. When I finally saw the file
in order to figure out why several internal static libraries weren't
getting built leading to some programs not getting built, I saw a
generic static library target made up of variables. fmake likes it;
bmake does not.
I tried USES+= fmake along with some patching but I must have missed
some hardcoded "make" commands because bmake got called again. This
software is 20 years old so I finally gave it. It got a stay of
execution by getting staged. If somebody wants to study a target that
bmake just doesn't get, this is a good place to start.
It would have been easy just to set this to "USE_GCC=any" to fix it,
but the code had plenty of undefined returns when a type was expected.
Using clang exposed those problems. Hopefully I defined the missing
return values correctly.
The CuraEngine is a C++ console application for 3D printing GCode generation.
It has been made as better and faster alternative to the old Skeinforge engine.
The CuraEngine is pure C++ and uses Clipper from
http://www.angusj.com/delphi/clipper.php. There are no external dependences
and Clipper is included in the source code without modifications.
This is just a console application for GCode generation. For a full graphical
application look at https://github.com/daid/Cura with is the graphical
frontend for CuraEngine.
The CuraEngine can be used seperately or in other applications.
Feel free to add it to your application. But to take note of the License.
WWW: http://wiki.ultimaker.com/Cura
PR: 192486
Submitted by: cederom tlen pl
The former maintainer indicates that he no longer has time to work on
this port. He understands is not staged and thus headed for removal,
so the RESTRICTED update is being done by itself in case somebody else
steps up to stage the port.
PR: 189883
Submitted by: maintainer (at the time) (Daniel Thiele)
Approved by: portmgr (implicit, NOT_STAGED)
I could not fix this port on clang. It finds the double argument to the
"to_string" function ambiguious and nothing I tried resolved the
ambiguity. In the end, I cheated by setting USE_GCC=any and I'll leave
the clang fix to a C++ expert.
Where possible, correct a few instances where PORTDOCS was being used
to flag stuff in EXAMPLESDIR. For some ports, mostly those owned by
ruby@, PORTDOCS is applied to pretty much everything whether it's
documentation or example.
- ports that set USE_SQLITE with the *_USE option helper
- ports that depend on libsqlite3 indirectly as reported by pkg rquery
Approved by: portmgr (implicit)
