Re: gEDA-user: xgsch2pcb config dialog

[Peter TB Brett <peter@xxxxxxxxxxxxx>]

On Tue, 17 Nov 2009 13:25:54 +0000, Peter Clifton <pcjc2@xxxxxxxxx> wrote:
> On Tue, 2009-11-17 at 07:07 +0000, Peter TB Brett wrote:
> 
>> > > * What is the format of the "extra gnetlist arguments"? Should the
>> > > options be preceded with "--"?
> 
>> They shouldn't.  (Actually, that field's a misfeature, IMHO.)
> 
> The option, or the fact that it gains a field in the xgsch2pcb config
> dialog?
> 
> The option was my doing.. I had a hacked version of gnetlist which
> needed to be passed extra arguments to make it work on a particular
> design. (Not totally unreasonable - the spice backend requires extra
> arguments, for example - not that it is relevant to gsch2pcb).
>
> I was using gsch2pcb to manage the flow, so I had to teach gsch2pcb to
> pass the extra arguments. Since they were non standard, I couldn't very
> well teach gsch2pcb about _that specific option_ and push it upstream.
> 
> I get fed up carrying lots of site-specific patches, so a generic "extra
> gnetlist arguments" option seemed a reasonable thing to have - even if
> it does come with a big fat caveat emptor about knowing what you're
> doing with it.

The option seems like a perfectly reasonable idea, but it seems
incongruously arcane for the options dialog in its current form (especially
given the option's "if you need to ask, you don't need it" nature ;-) ).

> 
> As Peter said, I gladly accept (good) patches. If people want to add a
> "--help" or "--version" argument, please go right ahead. xgsch2pcb was
> never really meant to be run from the command line, so it was never a
> priority for its original developers.
> 
> I don't like to retort "patches welcome" every time someone suggests a
> new feature, as that is both rude and unproductive - but there is only
> so much time I have available to work on features.

I don't like it either.  When I do so, it is usually for one of the
following reasons:

1. the requested feature or something very similar is on our "things we
want to do" list already, but hasn't been done because it's either
difficult, time-consuming or (more often) both.  In this case, "patches
welcome" should either be interpreted as an invitation to help out with
development in order to get nice things faster (if your glass is half
full), or to go away and stop nagging (if your glass is half empty).  As
you can imagine, with the current state of ongoing gEDA development, many
features fall into this category.

2. the requested feature is so far away from "regular" gEDA usage that I
don't expect any of the long-term gEDA developers to work on it due to lack
of interest.  Recall the back-scratching principle.  In this case, "patches
welcome" should be interpreted as an expectation that it won't ever get
done unless you do it yourself, but if you do, there's a good chance that
we'd be happy to merge your changes in.

In either case, if you *do* decide to take up the challenge, please come
and ask for help or suggestions about where to start looking in the code
(or about coding style, architecture, etc).  We'll do our best to help.


Peter


-- 
Peter Brett <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user