On 11/9/2019 2:18 PM, Jeff Young wrote: > Hi Wayne, > >> On 9 Nov 2019, at 19:05, Wayne Stambaugh <stambau...@gmail.com> wrote: >> >> Hey Jeff, >> >> On 11/9/2019 12:06 PM, Jeff Young wrote: >>> I’m working through the project Save As feature. >>> >>> I currently have it renaming the top-level files, updating the symbol and >>> footprint lib tables, updating paths in Gerber job files, and updating >>> paths and filenames in the netlist. >>> >>> A couple of questions: >>> >>> 1) The netlist I’m handling is a .net file which contains s-expressions. >>> Are there other formats I need to worry about? Do they also use .net, or >>> some other extension(s)? >> >> I don't think you need to copy files that are generated by KiCad such as >> netlist, gerber, and 3D model files. These can all be regenerated from >> the new project. > > Yeah, I thought about that (particularly in the case of a DRC report file). > I was sort of thinking it would be nice to keep them when we can, but not in > the case of the DRC (as we can’t guarantee that there aren’t non-discriminate > cases in the save-as algorithm, and we don’t want to certify a board as > having passed DRC in that case). > >> >>> >>> 2) Mention was made of updating sheet paths in .sch files. However, those >>> never refer to the top-level schematic, do they? If other sheet paths are >>> absolute then we shouldn’t update them, and if they’re relative then we >>> don’t need to update them. Or am I missing something? >> >> Relative paths will need to be updated if they are not contained in the >> current project path and the new saved project path is at a different >> branch depth in the path tree. Example: a sheet schematic path is >> ../some_other_path/some_other.sch and the project is saved to >> ../one_node_deeper/project_saved_as/, the sheet schematic path would >> have to be adjusted to ../../some_other_path/some_other.sch in order for >> the schematic to load correctly. This is the primary reason this >> feature does not exist yet. It's not as trivial as it would seem to >> implement unless you don't care about breaking the saved as project. > > I really don’t think we want to touch paths with “..” in them. How do we > know the user isn’t cloning a whole tree, and that the target of the relative > path is also getting saved-as and they want to keep the relative path the > same? We won’t generate that path automatically, so the user “owns” it.
This is exactly why I never tackled this one. Anytime your are trying to deal with complex relative path changes, the code gets rather messy. I doubt this will affect many users but you can be rest assured of a bug report if you get it wrong. > > Cheers, > Jeff. > >> >>> >>> 3) What about legacy schematic and/or board files? Any paths in those? >> >> Any relative 3D model paths suffer from the same problem described >> about. I'm not sure the 3D path code allows for relative 3D model paths. >> >> That's all I can think of at the moment but that doesn't mean there are >> not other issues that I've missed. >> >>> >>> Thanks, >>> Jeff. >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
