Mail Archives: geda-user/2018/07/23/22:23:07
On Mon, 23 Jul 2018, karl AT aspodata DOT se wrote:
> Yes, I've been bitten by that. For gschem I can have a gafrc in my
> project directory like:
Cool, so you have a partial solution: a gschem-specific file that can hold
only configuration but not sch names.
I still think it is a better solution to have one file and making it
able to hold:
- "any config our EDA tools need" to specify a project (not limited to
library search paths)
- and file names our EDA tools need to fully specify the project
- and whatever other thing, per tool, that is required to speficy the
project.
In theory having multiple files with or without using the same syntax
could also work, but on the long run you can't avoid redundancy (hacing to
specify the same settings on the overlaps) with that. It's easy: if two
programs need to cooperate, they either read the same piece of info from
the same file or they each have a different file to load the same piece of
info from. In the multi-file model you have three alternatives:
- specify the overlapping parts in multiple files because each tool reads
its own file only
- tools read each other files and pick out the parts interesting for them
(the overlaps)
- but that way each tool needs to understand each other tool's
config/project file, which is then not simpler than using a common file
and getting each tool understand that one.
> I guess it is this:
> http://repo.hu/projects/pcb-rnd/developer/lihata_format/tree.html#/lht_tree_doc/roots/geda-project-v1
Yes, that one.
>
> I don't see how that would be a solution to my case above, or should the
> program scan directories upwards to find it (e.g. gafrc or any other
> config files) like (I guess) git and svn does ?
It could scan upwards. At the moment, pcb-rnd and gsch2pcb-rnd doesn't do
that, tho. We have two theoretical cases:
1. you explicitly name the project file (e.g. on command line) - if with
full path, we don't need to look anywhere else, if without path it's in
CWD
2. we have a board file to work with and we pick up the project file - for
this we use the dir of the board file only. This is where we could start
walking upward to parent dirs in theory.
I'm not opposed to use parent dirs, but I think I won't do it before at
least one schematics editor joins. It can be that cschem will be the first
schematics editor to join.
> And I really don't see how that format would help me, for
> the "li:files", the list is simple the files found when starting from a
> top level source, like from the top level sch file. If I have to enter
> that in a config file, it would be a very annoying administrative overhead.
Each tool defines its own subtree with whatever data it needs. If your
tool needs only the name of a top schematics page, thenit can live with
that.
The idea is not to define centrally what each tool must store in the file
byte-to-byte. The idea is to define that the project file holds all
configuration and all necessary info to reach the files.
> For "li:libs", i.e. files referenced, but without a path given, well,
> something like that is needed. But I would rather like a default place,
> like a dir "sym" in current or any parent directory, then I wouldn't
> need to specify it in the first place, why have a config item if you
> can solve it in that way ?
If you want that in every single project, without special setting, that's
not a project-specific setting but a global setting then. That's an
alternative solution to a tiny part of the problem (one special conf
setting, the library path), and has nothing to do with project files.
And of course, we already have that in pcb-rnd: you can set library paths
in the conf tree relative to the board file. You cna thenput this setting
in the system config or user config and it will affect any project.
>
> And as you have said elsewhere, the lht file format is basically a
> memory dump of program memory, it isn't something that is nice to
> open with an editor with.
Sorry, you totally misunderstood that.
The lihata format is a generic tree reprsentation that is explicitly
designed to be easy to read and write by humans. This is well documented
in the design documents. You may or may not like the actual syntax, and I
don't attempt to change that.
That is about the lihata format.
What I said was a "memory dump" is the pcb-rnd _board format_, which is
stored in a lihata document. It is an almost 1:1 dump of the internal
memory representation. Not in a byte-to-byte way (e.g. no memory pointers
of offsets) but on a logical level: the structure of the lihata tree
follows the structure of the data how it is stored in the memory. This has
nothing to do with the lihata format - if we used xml, json, s-expression
or antyhing else, this consideration would be the same. This is how native
file formats generally work.
This does not affect the project file format in any way. The project file
format is designed to allow other EDA tools to easily join.
It's part of my eda ecosystem strategy: to come up with a _system_ of
independent eda tools. More about this:
http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=Iecosys
It's a layered system, but in the "tight ring" tools need to cooperate on
a few things, and the project file is one of them. If a tool wants to join
this ecosystem and fails to do so, it ends up in the "loose ring": it does
work togheter with (some of) the other tools, but it doesn't click with
the system.
On this regard, geda/gschem is almost as far from (or as close to) pcb-rnd
as kicad's eescham or ltspice are: pcb-rnd can import schematics from all
of these, the same way, but for example you can't easily specify your
project in a way both pcb-rnd and any of these schematics editors
understand it.
(The only reason geda/gschem is somewhat closer to pcb-rnd than the others
listed is that git versions of geda/gschem can do back annotation from
pcb-rnd while the others can't. geda/gaf also implemented the tEDAx
netlist format which will long term replace the current, "shared" scheme
script based forward annotation. Lepton is even farther out: it did none
of these and as far as I know, even the forward annotation path is broken
between lepton and pcb-rnd because the scheme script we use with
geda/gaf stopped working there and they don't support tEDAx.)
> Hehe, now that you mention it, I do have scrips and Makefiles.
> The gsch2pcb and pcb case is really annoying, so is the gschem case
> noted above.
>
>> (but I don't think majority of users would love the
>> idea of having 3..4 project files instead of 1).
>
> And there will "always" be +1 tool that doesn't understand the
> "common" project file, so "why bother".
Yes, that's the geda way: every tool must do everything totally
differently, any coordination between the projects must be avoided, etc.
And no, I don't think I invented the perfect project file format and the
whole world must use this. But we did implement something that is generic
enough and already works. For me the question is not whether this will
change the world (it won't), but whether a few tools that are often used
together can be used more efficiently -> EDA ecosystem.
So don't get me wrong, I'm not pushing this. pcb-rnd is not even part of
geda in any way. I am not asking any geda tool to do anything. I merely
describe (and offer support for) an option.
Pcb-rnd had, and geda still has this problem with lack of project files. I
think this affects majority of the users, but obviosuly not everbody. We
already have a project file format for more than a year now, that is
designed to be multi-tool, already implemented in two tools and other
tools can join if they want to.
If they don't want to, that's fine, they can invent their own formats or
just ignore the whole problem and do nothing. Whatever they think is best
for their users.
Regards,
Igor2
- Raw text -