On Tue, Jul 14, 2020 at 11:00 AM Christopher Sean Morrison via brlcad-devel <brlcad-devel@lists.sourceforge.net> wrote:
> Sorry, I may need some background — what problem is being solved? We > require Tcl now to build the samples, always have, and I’ve not exactly > seen that as a problem. I would leave well enough alone there. Cmake’s > done a great job with the dependency tracking. I wasn’t really envisioning > Tcl going away either, only Tk. > I wanted to be able to run a sizable chunk of the regression testing on the core libs with Tcl turned off - having pushed Tcl above libged, I'd like to make sure things are/stay working without it and the regression/unit tests are currently the best way to do that. However, many of them require the .g files for inputs, so in the "Tcl off" build they're not currently run. Whether Tcl will go away or not, I'd like to make sure it stays optional for the core. It looks like the v4 asc code isn't actually depending on Tcl hardly at all, so it should (in principle) be a fairly straightforward process to move it into libgcv. In principle I'm already most of the way there - I've got it moved and compiling, and I went through to de-globalize it. What I haven't tried yet is running it - it was in trying to set up examples for that part that I started finding problems with the current asc2g/g2asc tools for v4. If I can get it as functional as the current tools are that's enough for what I want right now, but given v4 may be lingering in obscure corners of the software world I wasn't sure if it was worth trying to squash the bugs as well. There’s semantic and testing value maintaining the samples in asc format > that would go away if they were 100% binary. A mix of formats and versions > is healthy and has caught issues. > I suspected that was probably the case. That being so, I'm game to clean up the asc code at least somewhat to get it into gcv - I'll just not worry about correcting any existing flaws in the current logic for the move. > We could switch them all to v5 asc and consider v4 asc formally > deprecated, but v5 asc is the specific path built on Tcl presently. Given > v5 asc is essentially a simplified transcript of ged commands, it probably > wouldn’t be hard to create a v5 asc gcv module that only relies on libged. > That's my plan. I agree it is almost certainly workable - the command set that g2asc actually writes out seems to be fairly small. Cliff
_______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
