#Brl cad rpm install#
#Brl cad rpm license#
#Brl cad rpm download#

The tkImg package only bundles those external dependencies for download convenience and can be disabled. It's worth noting a few updates since this recent set of updates about tkImg and tkHTM元. It will be great to see BRL-CAD integrated. Thanks to everyone else for taking the time to review and critique. We're looking into ways to refactor our modifications so they are an independent superset (so upstream is unmodified), but that's not where things are at today.īig thanks and appreciation to Matt Chan for taking this up. We need a, b, and c for the same reasons they did, so we have to implement a portion of what they intentionally remove. It's a fantastic library that provides (a) geometric representation and (b) conversion facilities, yet is a subset of their larger commercial Rhino SDK which includes (c) geometric analysis facilities. We're using openNURBS in a way that upstream specifically doesn't support.

NIST SCL: no upstream, heavily modified (we'll eventually manage it as a sub-project) OpenNURBS: some source mods, upstream is not interested (competes with their business) TNT: no source changes (it's only header files) Utah Raster Toolkit: no upstream, we apply security and build fixes (but otherwise do not modify) TkImg: no source changes, build convenience Tkhtml3: no source changes, build convenience here's the list of installable dependencies their status:

To get more specific on our external dependencies and respond to Toshio's request.

#Brl cad rpm install#

The solution there is to install our libraries in a sub-directory (e.g., /usr/lib/brlcad/librt.so) and update the system linker search paths so the conflict is avoided. Is there even such a thing? The problem has been simple naming conflicts as our core public libraries are sub-projects in themselves with trade mark identity. I'm really not sure what Matt meant by not following standard naming schemes. Additionally, there are compilation options to force all or individual dependencies on and off so that package management systems can be sure they're getting a system-installed library. We go to great lengths in our build system to perform compilation testing to detect installed libraries and to use them when we can. Our build aims hard to 'just work' by default, regardless of platform and environment. With the exception of openNURBS and NIST SCL, our external dependencies are unmodified and primarily provided as a download convenience for users. Alas, there is not a universal cross-platform package management system that we can rely on to be default installed cross-platform. We wish we didn't have to do that kind of thing too. To my knowledge, there is no project outside of BRL-CAD that makes use of their modifications to these libs. Is it still considered a good idea to abstract out the libraries, or should we just consider them a part of the BRL-CAD package? According to the BRL-CAD devs, they don't really resemble the original libraries/projects anymore.

None of those libraries listed should be present in fedora 11. TkHTML is a dead project as far as I know. It appears that they have made heavy 3rd party modifications to most of these libraries, especially Utah, Template Numerical, openNURBS, and NIST STEP, and the upstream projects are unwilling to accept them or are no longer active. I consulted with the BRL-CAD devs on the possibility of abstracting out the libraries while building this package. The libraries are somewhat of a sticky issue. I thought they were only trivial ones, but I didn't test the most recent changes.

#Brl cad rpm license#

I will have some time to work on this in the weekend to fix the license and rpmlint errors. I guess there's a downside to too many bugzilla emails. I'm sorry, I don't know how, but I missed the email about Kevin's comment.