1. the new "-attributes" (affects the previous test req with portmap) while working on devmap, I figured there was a bug in the implementation that kept the code from proper attribute merges, and that led to finding the missing error messages on attribute collision. Suppose you have a component that's done in 2 or more symbols. It's enough to set the footprint attribute on one of the (concrete) symbols, the resulting (abstract) component will have the footprint. But you are free to set the footprint attribute on 2 or more of the source symbols. When you do so, if the value of the footprint attributes are all the same, there won't be any problem merging them. If your footprint attribute values differ, but also have different priorities, the code can still make a good choice out of the contradicting values (picking the highest priority one). But if youhave multiple different footprint attrs at the same priority for the same component, that's a real collision and the code doesn't know which one to keep. It will throw an error message. All fine so far, but what's with the slot=N attribute? If you have a slotted component, typically all symbols will have a slot attribute, with different value, and you don't need this attribute in the component at the end. It seems I've missed this case in the original design. The solution is: if an attribute name (key) starts with a minus sign (dash, "-"), it is not copied into the final component. So instead of slot=3, write -slot=3. Note: the "-" is part of the name, it's not some special mark, just the first character of the attribute's name. I've also added the dash prefix to all the standard lib symbol's license/source attributes, and that's probably the good practice for your own symbols as well. Do not dash-prefix the attributes you _do_ want to end up in the component: devmap, portmap, footprint, other custom attributes, anything you need on the final output (i.e. netlist). The new feature is documented at: http://repo.hu/projects/cschem/design/04_attrib.html#des4:51 2. devmap You have seen portmap in the previous test req. It provided an easy way to specify the "pinout" of a device. It solves the "transistor problem": you can use the same generic symbol for different transistors with different pinouts, pinout described in an (array-typed) symbol attribute called portmap. In fact it is a bit more generic: - it can assign any scalar attribute to any of the ports of the given component from the portmap array - it handles slotting as well, so can assign different attributes of the "same" port in different slots But it sets only port attributes, it doesn't set component attributes. So one level higher we have another attribute, called "devmap", which is scalar. It refers to an external devmap file, which contains a set of attributes that should be set on the resulting component. In practice this external devmap file contains a footprint attribute and a portmap attribute (but could set any attribute). In other words: a devmap file is a full description that can connect a generic (light) symbol to a generic (light) footprint. So you can have a symbol-devmap-footprint setup, where devmap is a very thin glue layer, and the only thing that contains part-specific info. Besides portmap and footprint it could also set other device-specific attributes, vendor IDs for BoM, hints for DRC, etc. NOTE: these features are optional. You do not have to use devmap or portmap.You can go with heavy symbols, heavy footprints or both. You can use portmap without devmap. Or you can use devmap without portmap. I think the best way is using devmap with footprint+portmap attributes, so the default lib and default doc/tutorials will suggest this, new users would meet this setup first. For more details please read the devmap section if: http://repo.hu/projects/cschem/user/02_model/display_name.html Easiest way to test: - trunk/src/examples/devmap.lht ; click compile - or new empty sheet, place the opamp (or comparator) symbol from the lib, in two copies, use the attribute editor to change the -slot attribute to 1 and 2, then click compile 3. devmap file format The devmap file format is a real simple lihata doc which, at the moment, only lists attributes to add to the target component. The file format is documented at http://repo.hu/projects/cschem/user/03_data/devmap_ff.html but if you are familiar with the lihata syntax already, it's also easy to pick up from the existing examples. 4. library generalization: devmap libs We need to keep our devmaps somewhere... and that's really a library of devmap files. It doesn't differ much from a library of symbols: just a bunch of files with specific file names, containing some info about a part. So I've extended the librayr infrastructure in libcschem and it can handle any amount of parallel libraries of different classes. On class is the symbol library, another class is the devmap library. For now our minimal stock devmap lib is in trunk/library/devmap. I try to keep it small, but if we have enough files we can sort them into subdirs. Naming convention is up to the user; the stock lib uses partname_footprint.devmap. You can open the devmap library window using {w w d} (as seen in the window menu). The config node that sets search paths (so you can set up your own devmap lib) is plugins/std_devmap/search_paths. (We want to keep sheet files portable so devmap need to be embedded just like symbols. It's already done, but it will be part of a subsequent test request.) 5. quick edit attr for devmap Open the attribute edit (not propedit!) on a symbol that has the devmap attribute (or create the devmap attribute), then select it and click on the "assisted edit" button. This will bring up the devmap library dialog. Browse and select a devmap; the preview on the right side shows the attribute edits the devmap would do on your component in compilation. Click on the "use selected" button to modify the devmap attribute on your symbol.