delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2018/07/23/22:23:07

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Tue, 24 Jul 2018 04:28:30 +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: Re: Project file (was Re: [geda-user] gschem multiple pages)
In-Reply-To: <20180723195942.605CB841DEBA@turkos.aspodata.se>
Message-ID: <alpine.DEB.2.00.1807240343390.8169@igor2priv>
References: <CAGqyy=bsRdbA8r8q1MTX7pG9ASZiqpsw1-kbj=geTwLoWaz1sA AT mail DOT gmail DOT com> <20180723152807 DOT 13d27cadcd023b63aa3fd9c0 AT gmail DOT com> <CAGqyy=ZC68vU+8vpM4oai5=Mrfq_=QpyojzDwwW-50EV6P4q3A AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1807231832560 DOT 8169 AT igor2priv>
<20180723174658 DOT 32979841DEBA AT turkos DOT aspodata DOT se> <alpine DOT DEB DOT 2 DOT 00 DOT 1807232013250 DOT 8169 AT igor2priv> <20180723195942 DOT 605CB841DEBA AT turkos DOT aspodata DOT se>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com


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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019