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> Comments: In-reply-to gedau AT igor2 DOT repo DOT hu message dated "Mon, 23 Jul 2018 20:31:34 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-Id: <20180723195942.605CB841DEBA@turkos.aspodata.se> Date: Mon, 23 Jul 2018 21:59:42 +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: ... > > Whats the use for a "project file", isn't it sufficient to use the top > > level sch file ? ... > Now what if you want a different footprint lib and symbol lib in different > projects? What if you want to provide a self-contained tarball with local > libs, without embedding everything? ... Yes, I've been bitten by that. For gschem I can have a gafrc in my project directory like: (reset-component-library) (reset-source-library) (source-library "_sub_page") (source-library "part_a") (source-library "part_b") ... (component-library "sym") and when starting in dir. part_a, I can have: (reset-component-library) (reset-source-library) (source-library "../_sub_page") (component-library "../sym") I need the reset-things to disable the system and user config. with that I can cd proj; gschem top.sch or cd proj/part_a; gschem part_a.sch or cd proj; gschem top.sch and then hier-down to part_a but cd proj; gschem top.sch and hier-down to part_a, hier_up, then hier-down to part_a won't work, since there are no a (source-library "part_a") any longer. And I'm forced to include the src-lib in part_a's gafrc file also, which is annoying... And, yes, I can do, in gafrc: (reset-component-library) (reset-source-library) (if (access? "sym" R_OK) (begin (source-library "_sub_page") (source-library "part_a") (source-library "part_b") etc... (component-library "sym") ) (begin (source-library "../_sub_page") (source-library "../part_a") (source-library "../part_b") etc... (component-library "../sym") ) ) and using symlinks in part_a etc. or using abs.paths, but I'd like to avoid abs.paths since others place the project it in other dirs. And, then, what if there is part_a/sub_comp_x. Well yes, I write a script to generate gafrc files, so gafrc files isn't the solution. > With classic geda it's normally user config and then affects all your > projects, or it's somehow saved in schematics or board file (e.g. pcb's > import schematic's sch file names). The project concept is missing, while > poeple very often want to share and collaborate on projects, not > individual files. gschem can have a per directory gafrc files to override system and user configs. > When I figured this and introduced optional project files in pcb-rnd, as > an extra it brought some code and UI simplification: we don't have > different config for pcb-rnd and gsch2pcb-rnd any more and the plan is > that genxproj would work from the same project file as well. The project > file format is designed in a way that any tool can easily extend it by its > own subtree without interfering with other tools. I guess it is this: http://repo.hu/projects/pcb-rnd/developer/lihata_format/tree.html#/lht_tree_doc/roots/geda-project-v1 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 ? 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. 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 ? 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. > In theory there could be a separate project per tool file for the same > project, but I don't think that would be easy for the user. I don't mind per tool files, but it would be nice if the file syntax would be the same and if they are found even when working in subdirectories. > In practice > users often work this around with Makefiles or shell scripts, ... 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". I don't mind mult. conf files, but I do am annoyed if I have to specify e.g. the footprints dir name in multiple places. Regards, /Karl Hammar ----------------------------------------------------------------------- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden