Created attachment 199534 [details]
Unified diff - textproc/castxml Makefile, pkg-plist

CastXML provides a method for representation of functional declarations and type declarations for C and C++ software -- possibly also Objective-C -- in an XML model. Although the XML model used in CastXML does not provide any formal schema, but it may -- in effect -- serve as a normal grammar, albeit expressed in XML syntax.

CastXML uses LLVM and libxml2. CastXML may also use the sphinx-build tool from the textproc/py-sphinx port for generating the castxml manual page. The manual page would be generated from a source document in Restructured Text format, at build time.

This patch provides an update for the textproc/castxml port such that allows for selecting exactly one LLVM distribution to use, in a range from LLVM 4 up to llvm-devel. LLVM 3.5 and LLVM 3.8 have not been supported in this patch.

This patch does not provide any integration with the newer flavors system in FreeBSD ports. I hope that I may be able to provide a patch shortly, such that would use the flavors system and would allow for multiple concurrent CastXML installations, each using a distinct LLVM distribution.

This patch also updates the port, such as to allow for using py-sphinx to generate the castxml(1) manual page, during build time.

Lastly, this patch updates the port such as to explicitly declare the dependency on libxml2. Noting that the dependency is managed via CMake in the CastXML build, the declaration for the build dependency onto libxml2 -- in the patched Makefile -- makes reference to the file, libxml2-config.cmake. For the runtime dependency, it makes reference to libxml2.so

Things that this patch does not address, with regards to CastXML distribution in the ports system:

* Flavors. If I may understand the flavor system correctly, it should be possible to build and install multiple CastXML packages, such that each installed CastXML package would depend on a specific LLVM version, of those supported. Perhaps this may be somehow analogous to how so many Python ports may simultaneously support building and packaging for e.g Python 2.7 and Python 3 distributions, each from a single source port. 

* There have been a couple of changesets at the CastXML source repository - https://github.com/castxml/castxml - such that this port may be updated in the port's GH_TAGNAME and distinfo fields. This patch does not provide such updates.

* There's a test subdirectory provided in the distsrc filesystem for the CastXML port. As yet, this port does not provide any integration with any manner of a testing framework in the ports system. Pursuant to supporting CastXML development, perhaps it may be helpful to support any unit testing system used in CastXML, during the port build. Also, it might be nice to be able to include some example code with the port. Perhaps the testing code might also serve to represent such example code.

* Doxygen. It should be possible to produce an optional DoxyGen representation of the CastXML source code, during the port build. Theoretically, the Doxygen representation may be provided optionally in HTML and PDF editions, for purpose of reference.

* Integration with editor tools - e.g Eclipse IDE or anyone's favorite console-mode text editor. Perhaps this may be more to the matter of CastXML development, though.

HTH

- Sean