Mail Archives: geda-user/2018/07/24/09:54:34
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
- Raw text -