kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/30/2010 02:13 AM, jean-pierre charras wrote:
> Dick Hollenbeck a écrit :
>   
>> Jean-Pierre,
>>
>> I am not liking the change to the generic export format that you
>> recently made with respect to the component pin's netlist involvement:
>>
>>
>> 0) you never stated what problem you are trying to solve.
>>     
> I know 2 usual netlist formats:
> the first format has 2 (or more) sections:
> 	the first section gives a list of components (and associated footprints), without connectivity info.
> 	the second section gives the connectivity.
> 	Cadstar, pads-pcb and the intermediate netlist use this format.
> the other format use only one section:
> 	it gives the list of components and for each component, inside the component description, the list of pins and their associated net.
> 	Spice, OrcadPCB2 use this format.
>
> Of course there are other (more complex) netlist formats (Orcad uses an EDIF format),
> but these old formats are very simple because when they were designed (a long time ago), the "by hand" edition was sometimes used.
>
> the last change try to make very easy the netlist format conversion for both formats.
>   
>> 1) That information that you added is already in the file in a different
>> place. 
>>
>> 2) The file is needlessly larger.
>>
>>
>> Maybe I am alone on this issue, but I think to add the same information
>> twice to the file is silly.  I wrote the generic export format because I
>> did not like the old netlist export.  And now this one is like the old
>> one.  I find this fairly de-motivating.
>>
>> Please explain what the use case is, i.e. 0) and why it cannot be solved
>> by an intelligent loading function.  I think this is about 5 lines of
>> XSLT code, if I am not mistaken.
>>
>>     
> I am afraid my skill about XSLT code is very limited ( I just learn it to create the cadstar and orcadpcb2 outputs).
> I did not find an easy way (i.e. an intelligent loading function) to create the OrcadPCB2 netlist format (this is also the basic 
> format of Pcbnew Netlist) without adding the pin info in component description.
> Obviously this info is added twice (this is bad), but on the other hand, netlist export is trivial, whatever the output netlist 
> format.
>
> I'll be very happy if you send me a sample code to create the OrcadPCB2 from the first intermediate netlist format.
> I'll put this example in the new doc I wrote, and the (silly, I agree) pin list inside each component description will be removed.
>
> By the way, xsltproc.exe is easy to install under Windows (and, of course under Linux.)
> So all netlist export formats (Pspice, Cadstar, Orcadpcb2 and others ...) could be generated by the XSLT converter, and removed 
> from the kicad code.
>   

Thanks for clarifying 0), the use case.  The main advantage to using a
simple external tool for generating the final exports is that other
people can come by later and use those examples as models for future
work, (thus leaving us out of it).  If this was not going to be the
case, then relying on existing C++ code is still a viable solution to
supporting OrcadPCB2 format.  And one might also argue, that even if
there were going to be folks that use the XSLT samples as models for
future work, that the existing C++ code for OrcadPCB2 format is *still*
a viable solution.

Now, if we assume for a moment that providing examples is a good idea,
then the nature of the examples and the breadth of the examples are to
be considered.  We have designated xsltproc and python both as
reasonable tools that can be used to post process the generic netlist
format.  Therefore I ask, if I were to spend the time to create the
OrcadPCB2 format using an external tool from my version of the generic
export format, is there any reason why I must do that using xsltproc, if
the solution (in say python) ended up being a good example for other
solutions?


These are some things to think about for a few days while I free up some
time.  I like the lxml library in python, and if XPATH is the genius
behind XSLT, it also exists in lxml.


Thanks for not outright abandoning the idea that the generic netlist
format should actually continue to look as if it were actually
*designed*, and not simply evolved ad hoc.

Dick