kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

2016-01-12 23:02 GMT+01:00 Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>:
> Hi,
>
>
> On 12 Jan 2016, at 22:20, Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx> wrote:
>
> Having a single reference point is extremely inflexible - how do you handle
> user models? If a
> package manager installs the files and you add to the directories then your
> changes can be
> overwritten later. If the directories are read-only then the user can't add
> models. Some people
> use ${KIPRJMOD} or other environment vars in the model names to work around
> the current
> limitations. Even if we had a scheme like fp-lib-table different users will
> have to create
> corresponding nicknames on different installations.
>
>
> Is it really?
>
> I didn’t exactly follow what you plan, but looking at fp-lib-table:
> Every user has his own fp-lib-table… either referencing the system
> libraries, maybe github libraries, or his own custom ones.
> A user can pick system-libraries he wants from system path and his own ones
> from some location he has write access and the system package manager won’t
> overwrite (his home folder I guess).
> How libraries are referenced in fp-lib-table is pretty much on behalf of the
> user.
> He can use pure absolute paths or some other base referenced via some
> environment variable (don’t know at the moment if it is limited to using
> ${KISYSMOD} or you can use an env variable that is defined).
> Using such a variable I can customise my various installations by just
> setting the local variable to the right path where my (local/private) models
> are.
>
> So, for me this looks quite flexible?
> At least, it allows me to open *my* projects on different machines I work on
> with the same (my) library but maybe different filesystem layout.
>
> My point is not about exchanging projects between different users on
> different machines.
> Of course, if I open a (foreign) project which references 3d-models other
> than those I have, they won’t be found.
> But I don’t see any reason why this should be better when using relative
> paths…
> When exchanging projects, as you said… either projects have to be completely
> self-contained or all parties have to use the same libraries (or, model
> directory structure).
>
>
> Regards,
> Bernhard

Why do they have to be _either_? With Cirilo's scheme you can use 3d
models from differenct sources while you design your project. The
thing is that the system libs are installed on different locations on
different machines, we all know that, but that is why there is those
search paths you see in Cirilo's branch.

Just copying the fp-lib-table system to the 3d models, does not really
make much sense for me. As I see it the 3d models are highly tied to
the footprint, (this is ofc similar to the connection between the
symbol and the footprint, but lets not discuss that now), especially
because there is this alignmend and such that sort of make the "bond"
unique.

In my mind what would also solve a lot of theese problems, but still
having the benefit of having any lib easily available is to have a
finilize or archive options, that can for example take all your
"depends" and copy them to your project files or folders, such that it
is self contained at this point. It does not need to be self containd
while actually designing the board. While designing, you should just
be able to resolve paths to all your stuff.

To consider the slight issue with the same relative path and filename,
but different base paths. I guess a fp-lib-table system could be
adopted to the configure paths dialog, without being an advanced
interface like the fp-lib-table dialog is. Only containing three
entries like "nickname", "base_path", "description", whereas now it
just contains the env var and path. In the before three entries, the
envvars are paths like they are on the rest of your system, but I
guess you could use a "coloumn" to render the actual path too.

I am not exactly sure how this impacts the current file schema and
backwards compatibility. We can of only expect us to read old files,
but make the 4.0.1 read the new file formats, in case such are needed.