X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Wed, 6 Jul 2016 09:02:15 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: [geda-user] RFC: project files (pcb-rnd) and multiple pcbs (tabs) Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Reply-To: geda-user AT delorie DOT com Hi all, there's a flamewar-triggering topic: project files. I am trying to make non-intrusive, optional project files for pcb-rnd. I'm interested in geda user's feedback on my plans. As always, I am determined to carry this out, so it's not just yet-another-bike-shedding-thread: whether the thread yields useful comments or not, code will be written, and project file support will exist (... as it already did for ages, see later). So please try to be constructive to make the result better! As usual: nothing proposed for mainline pcb, geda, gaf, gschem. I am interested in pcb.geda/gaf/gschem user opinions to integrate them in the pcb-rnd, gsch2pcb-rnd and cschem toolset. *** First, how project files can be done without turning them into an Evil Tool Of Integration: A project file is a collection of settings and file names (paths) and metadata. It tries to fully or partially describe a project. It binds things in one direction: describes what the project consists of, but does not tie a given source (pcb, sch, etc) to a single project. In other words, it is for remembering how a project can be put together, but it does not affect the independency of each source file. Source files can be referenced from multiple projects. There can be source files never referenced from any project. A project file is totally optional: if an user feels the need to have a project file, he can have one; other users can use the same source files manually, totally ignoring any existing project file and complex projects can exist without project files. A project file can be partial: it's a collection of optional extra settings/info. When a project file is passed to a tool, any setting that is not specified to the tool (e.g. on command line) can be loaded from the project file. E.g. it's normal to use a project file to only specify library paths and leave input/output file names to a Makefile. Multiple tools can understand the same project file, but not all tools must understand it. Pro: the same settings (e.g. library search path for pcb and gsch2pcb) don't need to be specified/maintained in different files in parallel. Con: it's obviously impossible to get all existing tools to learn a single configuration language. It's not the goal either, see extraction/conversion later. Tools dealing with the project file are required to be able to pick out the parts they are interested in and leave unknown parts intact even in a load-save cycle. This obviously needs some generic container format. (For pcb-rnd my choice is lihata.) For tools that don't implement support for the project file: smallish utilities can be provided that extract parts of the project file and generate tool-specific rc, config or porject files. *** History The concept is not new. gsch2pcb had optional project files for ages, but they were not generic enough, e.g. library search paths had to be specified there and then explained to pcb too. The non-intrusive property has been there for ages too: gsch2pcb can work with and without project files. *** Motivation I often have small projects with multiple sch and pcb files and custom footprint and/or symbol settings. I don't really like that I need to keep multiple config files in sync to get tools work together on the project. If the same tools understand eachother's file formats, they should also understand some common config. If the way of undestanding file formats is through external or semi-external tools (e.g. gnetlist, gsch2pcb), perhaps the same way should be applied to the project file. As a programer I care about such implementation detail, but as an user I don't. I don't believe "different tools understanding a common standard" means "integration" or is evil by default. *** Next, what should go in a project file, and this is where I am especially interested in feedback. Please remember that any of these are optional and may be partial. A valid project file can even omit all of these and be empty (with some minimal header). 1. settings of tools; pcb-rnd already can read a config tree (as role CFR_PROJECT) from a project file. In practice this means any pcb-rnd configuration can be changed (weakly or strongly) from a project file. A common example is prepending or appending library search paths. 2. lists of files the project consists of; probably list per type, e.g. a list of schematics pages, a list of pcb files. Editors speaking the common project file language _optionally_ can load a project file, which at least means they can open all input files from one of the lists. As an optional extra editors can also load config subtrees from the project file (in practice: gsch2pcb-rnd and pcb-rnd load the same config tree from the project file so footprint library search path can be common). 3. metadata: project description, copyright, URLs to the VCS, comments, etc. *** PCB-related question: gschem can deal with multiple pages open, pcb and pcb-rnd can have only one file open. Is it worth adding "tabs" to pcb-rnd and let it open multiple files? Or is this a viable alternative: a "switch file" menu; when a project is loaded, the first pcb file is presented. The "switch file" menu is almost the same as the normal load dialog, but it offers only the pcb files referenced from the project file. Switching is still the same operation as load pcb, so only one pcb open at a time and you have to save before switch. This fake multi-pcb setup works only with project files, when a .pcb is loaded explicitly, the project is unloaded, "switdch file" is disabled. TIA, Igor2