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:	<alpine.DEB.2.00.1807232013250.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>
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
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

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

- Raw text -