X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sat, 12 Sep 2015 19:17:23 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] About reinventing the wheel, and how to avoid it
In-Reply-To: <20150912185302.18b30c02caf5e385b96184b8@gmail.com>
Message-ID: <alpine.DEB.2.00.1509121914510.6924@igor2priv>
References: <D3D5A923-FAF9-4665-A0DB-A8D6A8BEA5A3 AT noqsi DOT com> <CA+uY=MS5ZOTHXDe9taav+0tCiZOqhtAJU2KO-xyRA3SrQVvLNw AT mail DOT gmail DOT com> <201509112020 DOT t8BKKBgI012564 AT envy DOT delorie DOT com> <E872F1BC-8FA7-449E-BA6D-5841AC79A465 AT noqsi DOT com> <201509112058 DOT t8BKwF3b013774 AT envy DOT delorie DOT com>
 <6341DF3E-543D-4E36-9B01-6B5B950208C4 AT noqsi DOT com> <20150911230843 DOT GE7946 AT localhost DOT localdomain> <20150912021841 DOT 52f57f2d AT jive DOT levalinux DOT org> <55F3F5F2 DOT 406 AT jump-ing DOT de> <DF372225-A570-4A5C-B80E-B917FE60B594 AT noqsi DOT com> <20150912142006 DOT GA16820 AT localhost DOT localdomain>
 <20150912185302 DOT 18b30c02caf5e385b96184b8 AT gmail DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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



On Sat, 12 Sep 2015, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:

>> Actually, looking at these discussions over several years I think this
>> proposition is robust. IMO, we could make more proper relations between
>> gschem/gnetlist/gaf and pcb using
>>   1. either more serious integration (like KiCAD);
>>   2. or more serious separation, defining more robust interfaces
>>   gschem/gnetlist/gaf or pcb would need to exchange necessary data
>>   between the programs (so the mailing list separation would be useful,
>>   too)
>
> 2. pcb2pdf, pcb2gerber, pcb2eps, ... may be better than a integrated solution because it may for example work with a Makefile but I can't put any really good arguments for it right now.

You can use pcb in batch mode from Makefiles to make your exports.

The only practical drawback is that your computer loads a lot of code that is 
not really needed for the actual job - but I would be surprised if that'd 
be a hand-measurable time compared to the time spent on parsing the pcb 
file, building the in-memory representation, iterating over the objects, 
calling the exporter HID, etc.

Of course on a theoretical level it'd be nicer to have a separate parser 
lib that both PCB GUI and whatever exporters use.

Regards,

Igor2