Christopher Sean Morrison

We can certainly use Docker, and we have in the past (at least I used it a number of years back), but we've never considered requiring it. In general, we...

I agree that we want to keep generating the docs as there are numerous validation and integration benefits. That said, I think docs will eventually *need* to live in a...

> If we're going to go with a brlcad-docs submodule, then would the way forward be to set up a separate brlcad-docs github project and establish the new setup there,...

> The other option would be to bootstrap Ruby and use a local copy to drive asciidoctor - if it's simple enough to set up a self-contained environment, the new...

Various Government agencies use BRL-CAD within secured environments without online access. It's a primary use case that we must maintain and support. So, while docs can be in html and...

There's one change that was made to the sources due to a prior error: ```code diff --git a/src/GCommon/VectorHelper.h b/src/GCommon/VectorHelper.h index 095c46a..62f153d 100644 --- a/src/GCommon/VectorHelper.h +++ b/src/GCommon/VectorHelper.h @@ -28,11 +28,11 @@...

I dug into this a little deeper and the problem seems to be faulty CMake logic. Lots of your library dependencies aren't properly specified. For example GAppFramework uses GVis, but...

After applying a litany of changes from that patch (and a few more), I got a complete successful compile. However, all applications unfortunately crash immediately. Here's the stack trace: 0...

Thank you for the responses. The gist I'm understanding is that the dtoc tool cannot support any dlib network via xml, but only certain ones. Thus the syntax error in...

Alright, I can try compiling from source, but sounds good if the second issue is already known and fixed.