I left the Tcl/Tk headers as-is specifically for that reason - I was tempted to go all-in (or technically all-out) but I knew there was a virtual certainty that such a move would break client codes.
We may collide with system Tcl/Tk libs and headers, but it shouldn't come up until someone decides to link in a 3rd party library that in turn pulls in the system Tcl/Tk library. The likely (known) offenders in that category are zlib and png, with lz4 a likely candidate - those were my main targets of interest. Cliff On Thu, Apr 9, 2020 at 11:50 AM Christopher Sean Morrison via brlcad-devel < [email protected]> wrote: > > This will likely propagate breakage because AJEM and possibly other codes > have historically relied on BRL-CAD in order to get Tcl/Tk. We can change > that, but it may be worth announcing it as a breaking change, or at least > noting the work-around setting in docs somewhere. > > Cheers! > Sean > > > > On Apr 9, 2020, at 11:27 AM, starseeker--- via brlcad-commits < > [email protected]> wrote: > > > > Revision: 75317 > > http://sourceforge.net/p/brlcad/code/75317 > > Author: starseeker > > Date: 2020-04-09 15:27:40 +0000 (Thu, 09 Apr 2020) > > Log Message: > > ----------- > > With the deliberate exceptions of Tcl/Tk and openNURBS, don't install > the headers of the src/other libs. Our bundled versions aren't really > intended to (and can't always successfully) substitute for 3rd party libs > in other codes as well as our own, and putting our versions of those > headers where they can be found invites trouble. openNURBS we modify for > our uses (a system version, which doesn't usually exist anyway, won't work). >
_______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
