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 <adamw...@feelslikeburning.com>wrote: > (I agree with Marco.) > > > On Mon, Mar 17, 2014 at 12:01 PM, Marco Serantoni < > marco.serant...@gmail.com> 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 <lou...@yahoo.com>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 <adamw...@feelslikeburning.com> >>> 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.serant...@gmail.com> 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 < >>>> adamw...@feelslikeburning.com> 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 <lou...@yahoo.com>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 <stambau...@verizon.net> >>>>>> 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 < >>>>>> stambau...@verizon.net> wrote: >>>>>> >> >>>>>> >>> On 3/14/2014 5:32 PM, Marco Serantoni wrote: >>>>>> >>>> >>>>>> >>>> On 14/mar/2014, at 20:00, Wayne Stambaugh < >>>>>> stambau...@verizon.net> 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@lists.launchpad.net >>>>>> >>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>> >>> More help : https://help.launchpad.net/ListHelp >>>>>> >> >>>>>> >> >>>>>> > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Mailing list: https://launchpad.net/~kicad-developers >>>>>> > Post to : kicad-developers@lists.launchpad.net >>>>>> > Unsubscribe : https://launchpad.net/~kicad-developers >>>>>> > More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>> Post to : kicad-developers@lists.launchpad.net >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>> Post to : kicad-developers@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>> >>> >> >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
