Mail Archives: geda-user/2016/07/06/02:57:02
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
- Raw text -