X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f Date: Tue, 27 Oct 2015 13:18:37 -0400 Message-Id: <201510271718.t9RHIbRT021325@envy.delorie.com> From: DJ Delorie To: geda-user AT delorie DOT com In-reply-to: (gedau AT igor2 DOT repo DOT hu) Subject: Re: [geda-user] home/bkerin/geometry_module branch References: Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > I don't want to join another war here either, but CGAL is not all benefit > but has a cost as well. Sloccount on include/ in CGAL says 578k lines of > code. It's more than 5 times bigger than the whole PCB src/, > including the hids and everything. And it's all C++, while PCB code that > needs these calculations are mostly in C. 1. I have no problem with depending on external libraries, even big ones, when it makes sense. Does it make sense yet? How many actual 2D functions do we have in pcb already? Have we finished breaking them out so we know what could be replaced? I don't think we have good answers yet, so discussion is premature. Let's finish breaking out geometry.[ch] and see what we end up with. 2. I *do* have a problem with including external libraries in pcb's source tree. The right way to use a library is to link to it from it's officially installed version, not to include a private copy (in fact, including a private copy of a library may get you banned from some distros). Thus, the size of the library is somewhat irrelevent. 3. PCB's sources were converted to be C++ compatible at one point. Changes to (or additional use of) gdk/gtk constructs broke that. It could be fixed if it were needed.