kicad-developers team mailing list archive

[Marco Serantoni <marco.serantoni@xxxxxxxxx>]

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
>
>