X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox From: karl AT aspodata DOT se To: geda-user AT delorie DOT com Subject: Re: Project file (was Re: [geda-user] gschem multiple pages) In-reply-to: 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> Comments: In-reply-to gedau AT igor2 DOT repo DOT hu message dated "Tue, 24 Jul 2018 04:28:30 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-Id: <20180724132731.76074841DEBC@turkos.aspodata.se> Date: Tue, 24 Jul 2018 15:27:31 +0200 (CEST) X-Virus-Scanned: ClamAV using ClamSMTP 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 Igor2: > 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 don't have to specify the names, it's implicit: the files in the directory and subdirectories. > 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) Ok, fine with me, also would solve gsch2pcb-pcb problem. > - and file names our EDA tools need to fully specify the project ... I "know" the name of the top level file, do I really have to write it down too. Also, however many src files there are in "this" directory and down, I can run a dep-finding program. The top files are thoose that no other references. Do I really have to write this down myself, I'd rather write a dependancy-finding program than to have to enter file names into configs. > 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. I'm all for removing redundancy. > 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 One way to handle that is to "include" the common parts. That way I could include it in other projects as well. > - 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. The above two depends of the programs used, but since we are talking hypothetically, both gets the work done. > > 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: ... I think that pcb/pcb-rnd currently doesn't use much externally references (except footprints), so they don't need to scan, it's just one file to work on. With gschem/lepton-schematic you can have subpages scattered all over, and thoose relative path changes when you cd into another directory. > > 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 ... > 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. Ok then. > > 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. Oh, great. > > 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. ... No, I used the words in a sense that makes people misunderstand me. I regulary do that, I cannot detect it myself, I have to do damage control instead. And it also was an unneccesary reflection that doesn't have much to do with the topic. > 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. On the surface all thoose are fine. The problem is that they tend to be used in a way to avoid misunderstandings and that makes them verbose. So they are good if . you don't really look at them, only use them through programs . only occasionally need to look into them If you regulary read and write thoose files, the verbosity makes it hard to get the overview, you cannot make e.g. multiple pins line up table-wise and fit to the screen, and when writing there too much to type. And yes thoose conserns doesn't matter for most people, but it does for me. > This does not affect the project file format in any way. No. > The project file > format is designed to allow other EDA tools to easily join. Well, I cannot complain about that one. > 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 ... I'm all for cooperation, and I am sorry that there are so many obstacles for that, including myself. > > 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. ... Even if that is partially true, it sounds sarcastic. > Pcb-rnd had, and geda still has this problem with lack of project files. ... I think I react badly to the word project file, I get a feeling about beeing locked in. But if my scripts and makefiles could be easily be described in a project file that'd be fine also. Regards, /Karl Hammar ----------------------------------------------------------------------- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden