kicad-developers team mailing list archive

[Marco Serantoni <marco.serantoni@xxxxxxxxx>]

If you wish,
there are some old templates, look if you could do something with artworks
at:
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/files/head:/packaging/mac-osx/

There you can find my OOOOLD pkg maker (a pain), just ignore it.

And an old Jerry Script to make .dmg, that could be a good startpoint,
probably the artworks are reusable too.
Please use a FULL shell scripting approach if is possibile, i feel better
than native scripts and less problematic for all to manage and submit
patches (other scripts are binary, i don't like it due the difficulties to
make review).
Also please be aware that some paths will need an adjustment.


--
Marco


On Mon, Mar 17, 2014 at 6:03 PM, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>wrote:

> (I agree with Marco.)
>
>
> On Mon, Mar 17, 2014 at 12:01 PM, Marco Serantoni <
> marco.serantoni@xxxxxxxxx> wrote:
>
>> 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
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>