> > > If you just update the schematic and import the new net list, > > > doesn't that cause the trace for that net to be ripped up? > > > >It doesn't rip it up, but it does show up as a short. > > And how is that then fixed?
It's not fixed. You still have to edit the board to make it match the netlist; my process just makes sure that the board editing is always working *towards* matching the schematic, not *away* from it. > >Support in the applications for data and syntax they won't be using. > > I don't follow. The "syntax support" is just to ignore the entire > section that does not apply to schematic or whatever part is being > considered. That doesn't strike me as a lot of overhead. You still have to find the end of it, unless you use a syntax that can be parsed without understanding the content. And you have to remember it, so you can write out an updated file later. If the file only contains data you care about, you don't have to remember all the extra data. > >We've discussed XML before, and chose not to use it due to the uneeded > >complexity. Some other structured text format may be used though. > > What "uneeded complexity"? The XML parsing libraries are huge and have dependencies, in order to support the large degree of flexibility that XML offers. We don't need all that. It's overkill for us, esp since we already have an xml-like parser that's much simpler and very small. > The idea that the internal and external format could be the same > seems much simpler than to store in one format and then have to > convert to the other... of course this is assuming that the IPC > standard becomes adopted by industry. The "internal format" is going to be a binary data structure that's machine dependent. We can't just "store" that on disk. > But there is a huge advantage to being "standard". I agree, but if we can support a subset of the "standard" as an exporter, and still have a native format that works best for us, that's good enough. > Often people optimize things that are not really needed because that > is what they do. I'm not considering "optimizing" the file format. I'd rather design something less optimal but more flexible and future-proof. More of the design choices are about the data stored and its structure, not the format. Part of that relates to the internal data structure, which was designed a few decades ago. Changing that takes a lot of time and thought. _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
