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