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: References: <20180723152807 DOT 13d27cadcd023b63aa3fd9c0 AT gmail DOT com> <20180723174658 DOT 32979841DEBA AT turkos DOT aspodata DOT se> <20180723195942 DOT 605CB841DEBA AT turkos DOT aspodata DOT se> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Precedence: bulk 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