kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Hi Marco,

I'm glad you agree that .pkg is not a good option.  How do you suggest we
get data into /Library/Application\ Support/kicad?  Should we have users
drag a folder into there?

Adam Wolf
Wayne and Layne, LLC


On Mon, Mar 17, 2014 at 10:03 AM, Marco Serantoni <marco.serantoni@xxxxxxxxx
> wrote:

> Adam,
> 1) is the approach we will have dmg/zip file.
> 2) there was a package manager, but becomes an hell to configure put in
> bzr that forced us to remove few years ago.
> 3) Requires 1), applications are downloaded from a bundle.
>
> Jean-Paul, /opt is something that should be used for command line
> applications, not for GUI ones, try to interact with that will lead you in
> different behaviour of Finder between versions.
> Command line binaries related to Kicad should be placed in the bundle,
> like happens for Xcode with the compiler/SDKs.
>
> The
> /Library/Application Support/kicad is the path where the executables
> expect to find their data.
>
> Wayne is a common error, OSX is POSIX and have the BSD API but is not BSD
> in its organization.
> OSX has a mach kernel (not a BSD one) in which there is the BSD subsystem,
> like in the past NT had a POSIX subsystem.
> Like each distro have completelly different approach in package manager
> and organization for configuration files.
> I've already tried to explain why, that neither the pure wxStandardPaths
> before the K-way will work.
>
>
>
> --
> Marco
>
>
> On Mon, Mar 17, 2014 at 2:11 PM, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>wrote:
>
>> I think that'll work for users who want to compile their own.  From a
>> packaging and distribution standpoint:  I'm excited for kiways.
>>  Distributed Mac applications come in 3 types:
>>
>> 1) a DMG that contains a .app bundle that you drag to /Applications.
>>  This is basically what installing to /Applications does, except minus the
>> packaging step (which I already scripted)
>> 2) a .pkg installer.  These can install files all over your system, but
>> then uninstalling means running the .pkg again.  Users don't like these as
>> much as #1.
>> 3) from the Mac App Store. (Probably not a short term solution for us
>> right now--hopefully someday!)
>>
>> If we can set it up so that everything is contained in the .app, then we
>> can do #1 for distribution.  What's stopping us now from doing that is that
>> multiple .apps want to refer to the same libraries, so we have to have a
>> place outside of the .app that is common.  Once we have kiways, this should
>> be doable, right?
>>
>> Other Mac folks, what do you think?  (Other non-Mac folks too...)
>>
>> Adam Wolf
>> Wayne and Layne, LLC
>>
>>
>> On Mon, Mar 17, 2014 at 12:22 AM, Jean-Paul Louis <louijp@xxxxxxxxx>wrote:
>>
>>> Wayne,
>>>
>>> Thank you for your detailed reply.
>>> I will add -DCMAKE_INSTALL_PREFIX=/Applications/Kicad/ to my script,
>>> and the library files in /Library/Application Support/Kicad/ from my
>>> clone of github.
>>>
>>> I do not understand why we need two different repositories (bazaar for
>>> the software, and github for the data), but I can live with that.
>>>
>>> Anyway, every component used in my designs is always copied to a custom
>>> library that store only the components that I use.
>>> That way, I do not worry about anything related to my design being
>>> overwritten by an update, and I do not have to browse through hundred of
>>> files to find what I need.
>>>
>>> I will try this on my next build after renaming my current Kicad to
>>> kicad_old,
>>> and will post my results.
>>>
>>> Jean-Paul
>>>
>>>
>>> On Mar 16, 2014, at 7:14 PM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
>>> wrote:
>>>
>>> > On 3/14/2014 9:17 PM, Jean-Paul Louis wrote:
>>> >> Wayne,
>>> >>
>>> >> OS X is a strange beast.
>>> >> Apps are installed in more than one place.
>>> >> /usr/local/ is not visible from the finder, but /opt/local/ is.
>>> >> When I got a package prebuilt, it was installed in
>>> /Applications/KiCad/, which was fine.
>>> >
>>> > It sounds to me like the default install location for OSX installers is
>>> > /Applications.  I'm not sure why CMake is not using that as the default
>>> > install prefix.  It uses the correct paths on Windows and Linux.
>>> >>
>>> >> When I build from source with minimum interaction (cake, make, make
>>> install),
>>> >> /demos and /templates ends-up in /usr/local/share/kicad/.
>>> >
>>> > You can always override CMake's default install path by using
>>> > -DCMAKE_INSTALL_PREFIX=install_path to get KiCad installed where you
>>> > want it installed.
>>> >
>>> >>
>>> >> kicad is in several places
>>> >>
>>> >> Jean-Pauls-MacBook-Pro:kicad jean-paullouis$ sudo find / -name kicad
>>> >> Password:
>>> >> /Applications/KiCad/kicad.app/Contents/MacOS/kicad
>>> >> ...
>>> >> /usr/local/bin/kicad.app/Contents/MacOS/kicad
>>> >> /usr/local/lib/kicad
>>> >> /usr/local/share/doc/kicad
>>> >> /usr/local/share/kicad
>>> >>
>>> >> I am trying to find a way to have all the *.app under the
>>> /Applications/KiCad/,
>>> >> and all the data under the home directory, so I can update/upgrade
>>> without touching the data.
>>> >> ~/Documents/ would be acceptable, I would prefer ~/Data/.
>>> >> Github is OK for storage, but local storage is better for
>>> efficiency/load.
>>> >
>>> > I would not put the component or footprint libraries in your ~/ folder.
>>> > This will remove the temptation of modifying them only to have them
>>> > overwritten the next time you update them.  It's best to create new
>>> > libraries and leave the default libraries unchanged.
>>> >
>>> >>
>>> >> What is the best route to do just that?
>>> >
>>> > You should be able use git to create your own branch form
>>> > https://github.com/KiCad/kicad-library.  The CMake installer file is
>>> > still there so you can run cmake -DCMAKE_INSTALL_PREFIX=path_to_intall
>>> > and then make install.  I'm guessing you will have to have admin
>>> > privileges to install them in the system paths so the sudo command
>>> > should work.  If you choose this option, you will have to periodically
>>> > pull the changes from github to keep your libraries up to date.
>>> >
>>> > Wayne
>>> >
>>> >>
>>> >> Regards,
>>> >> Jean-Paul (AC9GH)
>>> >>
>>> >>
>>> >>
>>> >> On Mar 14, 2014, at 7:08 PM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
>>> wrote:
>>> >>
>>> >>> On 3/14/2014 5:32 PM, Marco Serantoni wrote:
>>> >>>>
>>> >>>> On 14/mar/2014, at 20:00, Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
>>> wrote:
>>> >>>>>>
>>> >>>>>> The idea of keeping Kicad libs in Github is great, but if the
>>> >>>>>> first-time-ever user has to set it up in some system config files
>>> or run
>>> >>>>>> bash scripts (think of Windows users!), it will ruin his
>>> experience
>>> >>>>>> (sorry for sounding Steve Jobs-ish...). Eagle, DesignSpark and
>>> Altium
>>> >>>>>> have libraries working out-of-the box. Why we shouldn't?
>>> >>>>>>
>>> >>>>>> My proposal is add a configuration window (see attachment) that
>>> appears
>>> >>>>>> the first time freshly installed Kicad is launched. What do you
>>> think of
>>> >>>>>> this approach?
>>> >>>>>
>>> >>>>> Hey Tom,
>>> >>>>>
>>> >>>>> Yes I agree that it should just work and it should.  The problem
>>> is not
>>> >>>>> in the code AFAICT.  The problem appears to be in the location
>>> where the
>>> >>>>> default fp_lib_table file is installed on OSX.  When either CvPcb
>>> or
>>> >>>>> Pcbnew are run for the first time without a define fp_lib_table
>>> file in
>>> >>>>> the user's platform dependent home folder, an attempt is made to
>>> copy
>>> >>>>> the default fp_lib_table file to the user's home folder.  On Linux
>>> the
>>> >>>>> default fp_lib_table file is stored in /usr/share/kicad/template
>>> and
>>> >>>>> copied to ~/.  If the default file cannot be found, then there is
>>> no
>>> >>>>> choice but to create an empty fp_lib_table file which is what
>>> appears to
>>> >>>>> be happening on OSX.  The path(s) searched for the default
>>> fp_lib_table
>>> >>>>> are defined in EDA_APP::FindLibraryPath().  If the path that the
>>> OSX
>>> >>>>> installer is placing the default fp_lib_table is not in the list of
>>> >>>>> paths, then that is the problem or there is potentially a file
>>> >>>>> permission problem preventing the file from being copied.  This
>>> used to
>>> >>>>> work fine on both Windows and Linux so if no one changed it, it
>>> should
>>> >>>>> still work.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> Wayne the problem is not the code and this is CLEAR.
>>> >>>> The problem is that there isn't an installer to install programs
>>> under OSX, that can be placed by the user anywhere under /Applications
>>> directory.
>>> >>>> The other issue is that the /Applications directory is not supposed
>>> to guest "support files", so the combination of the two things doesn't
>>> allow me to hardcode it on FindLibraryPath.
>>> >>>> I've also tried to think an arrangement on that, but interacting
>>> with Dick on ticket  #1267911, i've understood with error that EDA_APP is
>>> gone, letting me wait Kiway.
>>> >>>> </code>
>>> >>>
>>> >>> Where do the KiCad template files get installed on OSX when you
>>> install
>>> >>> KiCad using the OSX bundle?  That is where the the path should point
>>> to
>>> >>> when attempting to copy the default fp_lib_table file to the users
>>> home
>>> >>> folder.  I would prefer not use EDA_APP::FindLibraryPath() but rather
>>> >>> wxStandardPaths::GetDataDir() with the appropriate subfolders added
>>> so
>>> >>> this works out to be:
>>> >>>
>>> >>> Windows: path_to_kicad_binary/../share/templates
>>> >>> Linux: prefix/share/kicad/templates
>>> >>> OSX: kicad.app/Contents/SharedSupport/templates
>>> >>>
>>> >>> This is valid for windows and linux.  Is this not valid for OSX or
>>> are
>>> >>> you saying that you cannot copy a file from the application install
>>> >>> folder to the user's home folder?  I really am confused because I
>>> >>> thought OSX was essentially BSD which should be posix compliant.
>>> >>>
>>> >>>>
>>> >>>> <user_interaction>
>>> >>>> The limit of the previous approach is that the developer/packager
>>> choose for the user if use the old libraries or the GitHub approach, not
>>> letting the user choose what is better for him.
>>> >>>> Probably the "startup configuration window/wizard" could be a mayor
>>> enhancement for the user and solve also the other issue in a single move.
>>> >>>> This was also the spirit that I had when the 31/12/2013 on the ML
>>> i've asked a button to "fill in" the table starting from the old legacy
>>> library path.
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Marco
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> 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
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>