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 16:00:26 +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: <20180724132731.76074841DEBC@turkos.aspodata.se>
Message-ID: <alpine.DEB.2.00.1807241544510.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> <alpine DOT DEB DOT 2 DOT 00 DOT 1807240343390 DOT 8169 AT igor2priv> <20180724132731 DOT 76074841DEBC 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 Tue, 24 Jul 2018, karl AT aspodata DOT se wrote:

> Igor2:

>> 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.

It already _did_ solve that. We have this in place.

>
>> - 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.

How file name listings get into config files is a question of software. I 
prefer to have a list of explicit file names because that's easy to 
reproduce in random tools written in random languages running on random 
host operating system. Much easier than some smart file find/listing 
solution, no matter how simple the listing/pattern matching is.

>>
>> 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.

Yup, but again, before I do anything about this in the file format (... if 
I need to, at all), I want to see if gschem wants to join. If not, then I 
will do it when cschem is up to speed - no need to rush with the project 
file.

>> 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

I disagree. I find lihata easy to read and edit. But there's no format 
everybody likes equally well, and the line/field based formats won't 
extend easily into a tree, which in turn can limit what data you can 
represent even in memory. (In pcb-rnd we already have a full tree 
in-memory so we must have a file format that can handle that).

> 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.

It matters for me too, and I still disagree that it would be hard to read.

But we can cut this short: it's how it is, you don't like it, but it's 
very unlikely to change so we can skip (and avoid triggering the annual 
file format flame war, lol).

>> 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.

The project file I introduced in pcb-rnd is an option. You don't have to 
use it so it can't lock you in.

I think some of the simpler scripts/Makefiles could be described in a 
project file. Especially with the latest cam export improvement in 
pcb-rnd, it's now possible to do more complicated, multi-output exports 
from configuration. So there's certainly some overlap, and some 
cooperation: you can decide which parts you want to put in configuration 
and which part in scripts (including Makefiles).

However, we should keep project files generaly simple and more 
specifically: pure data. So a project file should not be as powerful as a 
generic purpose Makefile or shells script, executing arbitrary commands 
and logics.

It should be powerful enough to cover all aspects of the most common use 
cases so that users have a simple solution for the simple problems; then 
for a more complciated problem you can combine it with Makefiles or 
scripts, or you can totally leave out project files and do everything from 
Makefiles and scripts.

Regards,

Igor2