kicad-developers team mailing list archive

[Cheng Sheng <jeru.sheng@xxxxxxxxx>]

On 29 May 2017 at 09:40, Sergey A. Borshch <sb-sf@xxxxxxxxxxxxxxxxxxxxx>
wrote:

> On 28.05.2017 23:49, Cheng Sheng wrote:
>
>> I myself prefer storing all files specific to the project within the
>> project directory, including datasheets, components, adjusted footprints
>> and scripts. This way makes things easier when I copy the project around.
>> After all, I don't mind disk space waste on a few duplicated datasheets;
>> they don't take much space.
>>
> Ok, what is your workflow? You choose component, pick it from library into
> schematics and then manually copy it's datasheet (from where?) into the
> project folder to make it available from schematics?
>
I'm not a professional on electronics so I don't (want/bother to) maintain
a centralized collection of datasheets. Instead, when I select components,
I do parametric search on digikey/mouser/whatever, then check datasheets on
the website, download to project dir if chosen.

>
> I have my library and my project both under version control system, so I
> use latest, exactly the same (with all latest error fixes) library and
> latest, most actual datasheets in every project. But I always can easily
> revert library repository to state it was when project was finished.
>
I admire your patience and professionalism. I see your spirit to reuse as
many things as possible. Shared library has its reuse benefit. Of course,
also has its downsides. Eg., I don't necessarily remember how the shared
libraries are setup one year after I finish a project or after I move to a
new machine. So I prefer each project to be as self-containing as possible.

Of course, putting everything inside the project also has its downsides,
maybe even more than your proposed shared library approach. But I suppose
this is just personal preferences. Unless there's a strong reason why my
personal preference is terrible (that it is worse than a "standard
approach" in ALL aspects) or by following this preference my patch makes
the software terrible, it shouldn't be forbidden, right?


> There is "Archive library" option in eeschema File menu, which extract
> from library all components used in project. It can be extended to extract
> datasheets as well if it doesn't do it right now.
>
hm... Am I missing some compile options? I don't see such an option in
eevschema. Instead, only an "Archive Current Project" item in the project
window.

Anyway, even if datasheet extraction is added to "Archive library", you'll
still need a way to open a relative datasheet unless the archiving leaves
an absolute path (which seems unlikely the case, by guessing).

>
>
>> If the direction of move by the patch makes some other workflow styles
>> harder to optimize in the future, please let me know. I don't mind
>> alternative proposals that can fulfill more workflow types. What I wrote is
>> just a "shortest-path" I can see based on my own workflow.
>>
>> Regards,
>> Cheng
>>
>> On 28 May 2017 at 20:53, Ingo Kletti <ikletti@xxxxxxxxxxxxxxxx <mailto:
>> ikletti@xxxxxxxxxxxxxxxx>> wrote:
>>
>>     Am 28.05.2017 um 18:47 schrieb Sergey A. Borshch:
>>
>>         On 28.05.2017 14:35, Cheng Sheng wrote:
>>
>>             So I made a patch to resolve the path before it is passed to
>>             "wxLaunchDefaultBrowser()". If it looks like a URL or is an
>> absolute
>>             path, doesn't do anything; but if it is a relative path,
>> append
>>             "${KIPRJMOD}" to it.
>>
>>         Are you storing all datasheets in every project? I think it's
>> better to
>>         keep one copy per library, so path must be relative to library
>> location.
>>
>>
>>     Don't know about the OP, but from past experience it is wise to store
>> the
>>     datasheet for the different components tpgether with the project
>> files. That
>>     way you always have the specs available that your design is based on.
>>
>>     So a relative path makes sense depending on the use case and workflow.
>>
>>     Regards,
>>
>>     Ingo
>>
>> --
>>
> Regards,
>   Sergey A. Borshch            mailto: sb-sf@xxxxxxxxxxxxxxx
>     SB ELDI ltd. Riga, Latvia
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>