X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=EYivrLgrJTEDVWgvuGtMROXaw97sjeNA/nIQ6v7TXJA=;
        b=uUvvDkNDzGouuo8qofNDc/Fcf20NG7Rsi+6Vho7ZExyW1t11/n3TRUtnx/A2S9BcGF
         5AE3kXpqzs+TzO6+lTmMxL+Mw9ZDMkbNn73suB8bkgfaAuuOem+to7S5mysmT5EmblWv
         gZGQA5NC97GvjMqzMXAVFzdj6LfXuyk7nMfb1gAqk9ghPKzJX1OGQLYM2iwO4jZZlXjq
         LOdL350x//gzn8iGAF97NN/GuWqNpxfxZA2PcMXx///Bb9X3Ztc6mTLQAB6Pk3gdioLQ
         A/DzuY62EjRZH4s1qbEThoMTcS2OIDVSlG+bz4PcEDkuOXtN8N2bThbw69boKxE2a/8F
         NEmw==
MIME-Version: 1.0
X-Received: by 10.107.16.169 with SMTP id 41mr5591675ioq.33.1423157463147;
 Thu, 05 Feb 2015 09:31:03 -0800 (PST)
In-Reply-To: <alpine.LNX.2.02.1502050729450.24630@localhost.localdomain>
References: <1420499386 DOT 3521 DOT 3 DOT camel AT cam DOT ac DOT uk>
	<20150202152654 DOT GA13336 AT cuci DOT nl>
	<54CFD589 DOT 9040702 AT xs4all DOT nl>
	<CAHBYzfRkn-nJb4JfrDYyaD0WwPrpZvAgi0QdHCusgz185iNoHA AT mail DOT gmail DOT com>
	<CAGde_xN-iNZUvHh-E47kx1EyoPRt1018wWiDwHhYQ9+od+cJwA AT mail DOT gmail DOT com>
	<20150203112631 DOT 3507a0c1 AT Parasomnia DOT thuis DOT lan>
	<20150204054256 DOT Horde DOT Pm1JV8RJbICk9SHvIGwZ7A3 AT webmail DOT in-berlin DOT de>
	<CAOP4iL2stWVCy3WK0=SNu2zAbs8t6B0uyAgFuOnzG8v_MrYNfw AT mail DOT gmail DOT com>
	<20150204073758 DOT Horde DOT czAmF2JsXvWH254t3K1lrw2 AT webmail DOT in-berlin DOT de>
	<alpine DOT LNX DOT 2 DOT 02 DOT 1502040133260 DOT 5201 AT localhost DOT localdomain>
	<201502041241 DOT t14Cfd30005029 AT envy DOT delorie DOT com>
	<CAOuGh89YXTP2GN1gvPXm=iTYRF0eTxiTZfyU_-1Dx+ZmeM0jwQ AT mail DOT gmail DOT com>
	<alpine DOT BSF DOT 2 DOT 00 DOT 1502041223340 DOT 7094 AT earl-grey DOT cloud9 DOT net>
	<alpine DOT LNX DOT 2 DOT 02 DOT 1502050414490 DOT 24630 AT localhost DOT localdomain>
	<alpine DOT BSF DOT 2 DOT 00 DOT 1502050759100 DOT 55344 AT earl-grey DOT cloud9 DOT net>
	<alpine DOT LNX DOT 2 DOT 02 DOT 1502050729450 DOT 24630 AT localhost DOT localdomain>
Date: Thu, 5 Feb 2015 08:31:03 -0900
Message-ID: <CAC4O8c_BfK0JaxYs7U8XFe2++NG0MYXtSOYhRrWe7w+_BcBRAA@mail.gmail.com>
Subject: Re: Footprint generation.... was: Re: [geda-user] FOSDEM
From: Britton Kerin <britton DOT kerin AT gmail DOT com>
To: geda-user AT delorie DOT com
Content-Type: text/plain; charset=UTF-8
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 Thu, Feb 5, 2015 at 4:40 AM,  <mskala AT ansuz DOT sooke DOT bc DOT ca> wrote:
> On Thu, 5 Feb 2015, Stuart Brorson wrote:
>> > important and valuable.  It seems a shame that gEDA once had that ability
>> > and now basically doesn't.
>>
>> Also, the path most people take w.r.t. defining similar footprint sets
>> is to use scripts or programs to generate families of footprint files
>> all at once.  For example, John Luciani maintains a fabulous website
>> containing lots of footprints he generated using Perl:
>
> Yes, and I've got my own Perl scripts to automatically generate suites of
> symbol files containing the attribute data that the FAQ says I shouldn't
> want.  It appears that anyone who is using these tools, as I am, must
> become a toolsmith to build the necessary features that aren't included.
> We're all doing that for ourselves individually.
>
> Aren't such scripts exactly the kind of "workflow automation" that people
> are wishing, in this thread, gEDA would supply instead of forcing us all
> to build for outselves?  Whether the scripts are run online, with their

Yes.  I believe the problem is that nobody feels that their own personal
tools are really good enough to be worth promoting as "the solution".
Mine certainly aren't.  When someone does make a nice tool for part of the
process they share it (e.g. recent footprint generator).

I almost wish symbol/footprint production could be split to front-end/back-end.
Something like how debian builds packages with a (fairly) uniform Make
interface for a big variety of software build systems.  This would at least
let people share their existing symbol libraries (in source form, which
is likely to be a lot more useful given the relatively small size of the
libraries compared to the number of parts available).  If some particular
back-end takes over, so much the better.

So you might end up with:

     make list-parts
     make build-part PART_NAME=foo
     make view-symbol PART_NAME=foo  (launch gschem to see how it looks)
     make view-footprint PART_NAME=foo  (launch pcb to see how it looks)
     make view-datasheet PART_NAME=foo
     etc., including light-symbol and glue operations

with per-library back-ends implementing these operations in their own way.

Britton