kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #12753
Re: Local Variables
Jean-Paul,
I don't agree with "Programs".
Until now OSX has supported /Library/Application Support/kicad and
$HOME/Library/Application Support/kicad
(Order: Own Home before, then system one)
To be failsafe we could arrange a .dmg with a Symbolic Link and the Arrow
"Copy here", is a well know approach for OSX users, here some links with
examples:
http://jhelioviewer.org/imgs/JHelioviewer_OSX_installer_screenshot.png
http://www.visitusers.org/images/1/10/VisItMac_dmg.png
http://ruby.bastardsbook.com/assets/images/fundamentals/installation/run-code-step-by-step/mac-textwrangler-dmg.png
The issue in this case will be the $HOME/Library[..] link that we could
ignore for the moment.
This simplification could be not sufficient for a machine that is used from
multiple users.
pkg is not a "not like", just we got issues in the past with it that a
simpler approach could avoid.
--
Marco
On Mon, Mar 17, 2014 at 4:47 PM, Jean-Paul Louis <louijp@xxxxxxxxx> wrote:
> Hi Adam and Marco,
>
> I agree with both of you. Let's keep it simple.
> A DMG bundle that have a "Kicad" folder with all the apps to be dragged
> into /Applications/.
> Data Bundle in "Kicad" folder to be dragged into /Library/Application
> Support/.
>
> We could have a small app which move everything to the right locations.
>
> my $0.02,
>
> Jean-Paul
>
> On Mar 17, 2014, at 11:14 AM, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>
> wrote:
>
> 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
>>>
>>>
>>
>
>
Follow ups
References
-
Local Variables
From: Dick Hollenbeck, 2014-03-14
-
Re: Local Variables
From: Adam Wolf, 2014-03-14
-
Re: Local Variables
From: Wayne Stambaugh, 2014-03-14
-
Re: Local Variables
From: Tomasz Wlostowski, 2014-03-14
-
Re: Local Variables
From: Wayne Stambaugh, 2014-03-14
-
Re: Local Variables
From: Marco Serantoni, 2014-03-14
-
Re: Local Variables
From: Wayne Stambaugh, 2014-03-14
-
Re: Local Variables
From: Jean-Paul Louis, 2014-03-15
-
Re: Local Variables
From: Wayne Stambaugh, 2014-03-16
-
Re: Local Variables
From: Jean-Paul Louis, 2014-03-17
-
Re: Local Variables
From: Adam Wolf, 2014-03-17
-
Re: Local Variables
From: Marco Serantoni, 2014-03-17
-
Re: Local Variables
From: Adam Wolf, 2014-03-17
-
Re: Local Variables
From: Jean-Paul Louis, 2014-03-17