On Tue, 17 Nov 2009 13:25:54 +0000, Peter Clifton <[email protected]> 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 <[email protected]> Remote Sensing Research Group Surrey Space Centre _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
