X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=date:from:to:subject:message-id:in-reply-to:references:mime-version
	:content-type:content-transfer-encoding;
	bh=nvaxPUU+0YPPLqatuMVJKqW7MHxzGo8IsMD6SZ958bk=;
	b=eEKPMjXiPoIqZdL4fLYREZnEdKQ5Pu4YzaOjnwBToG6ezbVrR/0H+q8p6Zq/u8dqu6
	+UmrhrPc7B/C4rjUQUbZxQdI1Lvk5ZXIjA2dPKzWDxZUYiRlYkZDEnBBIroxs8wKDaDG
	IV5tcvBUs4LDdoDBsSdWDDeShg3H/25RZlCl2T7aeNT1C6CMq29qGarS6/KDx+R1kaPO
	B16c/+AaAtPDntoBWvw87kGCGSP66ribcND7pRWTfxi7GyoCdvXqukV0EY6t8LJR5Aub
	idSbGrxXtD0OKazqELo6E3UepR5gp7zTXfXa4/GKO5TxI4XCnKV4b0pyJj04Vtnci5oj
	DiEg==
X-Received:	by 10.194.110.37 with SMTP id hx5mr6524475wjb.149.1442054392127;
	Sat, 12 Sep 2015 03:39:52 -0700 (PDT)
Date:	Sat, 12 Sep 2015 12:39:47 +0200
From:	"Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] shortest way towards parsing .pcb files outside pcb
Message-Id:	<20150912123947.d16cac119dd3cb28fa3b4071@gmail.com>
In-Reply-To:	<55F3FD8F.4090709@jump-ing.de>
References:	<CAC4O8c_XFEAgyrokrwwavB0C+OjWXCB5xptkVwMx2i_t960qFg AT mail DOT gmail DOT com>
	<55F3FD8F DOT 4090709 AT jump-ing DOT de>
X-Mailer:	Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version:	1.0
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

> > Speaking of the parser, I think the easiest way to get an accessible
> > version of it would be
> > to add a structure that corresponds one-to-one with what goes in a .pcb file.
> > The parser could load stuff into that.  The current  "PCBType"
> > structure (really a sort of global application context) could be
> > filled in from that structure, rather than incrementally during the
> > parse.
> > Would this offend anyone?
> 
> ...
> 
> A more worthwhile goal might be to /replace/ pcbs current storage and
> storage handling. Code which fits into a library and is used by pcb as
> well as by other layout handling applications. Certainly not a trivial
> task, but it could help greatly to de-obfuscate pcbs code. In case you'd
> ask: partitioning of xorn code looks good, usage of plain C would be an
> advantage.

/replace/ pcbs current storage and storage handling with code which fits into a library and is used by pcb as well as by other layout handling applications sounds good. Then there may also be separate programs like pcb2eps, pcb2gerber, ... as someone suggested earlier and even if they are separate programs they may of course be run from a menu item inside the graphical gui. Separate programs may however also be used by make even though I can't argument for it right now.

- Raw text -