kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #12759
Re: Local Variables
Wayne,
The one with scripts is pkg not DMG that is DiskiMaGe that allows only to
popup a License Terms.
We had A LOOOT of issues with pkg in the past, we have sincerelly tried to
use it but the issues were more than the successes.
I could agree about github/old libraries confusion.
But you forgot we haven't a official distribution for library at the
moment, and also one only backward compatibility one should be provided.
The old libraries will be downloaded in the future only by users that have
OLD projects, the default will be github.
Options will be in my intentions:
* Start with old libraries
* Start clean
Then add/setup GITHUB via GUI, an apt-get approach will be nice to have
IMHO, i setup the repository he gives the libraries avaiable.
--
Marco
On Mon, Mar 17, 2014 at 6:18 PM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx>wrote:
> On 3/17/2014 1:03 PM, Marco Serantoni wrote:
> > Obliusly a second .dmg with only libraries to avoid confusion and adding
> > the possibility for the user to be archived if needed.
>
> Can't this be rolled this into one installer? The CMake and Freecad dmg
> files seem to include all the necessary samples, libraries, and
> documentation files all in one dmg file. I also noticed that there are
> pre and post install scripts that could be used to set things like
> environment variables as well. The contents of dmg files look a lot
> like deb files in terms of capabilities. Maybe you can provide an
> installer with just the apps and the docs for folks who are going to use
> the github plugin and another installer that also includes all of the
> libraries. I think having separate installers for the apps and the
> libraries is going confuse users.
>
> Wayne
>
> >
> > --
> > Marco
> >
> >
> > On Mon, Mar 17, 2014 at 6:01 PM, Marco Serantoni
> > <marco.serantoni@xxxxxxxxx <mailto: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
> > <mailto: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
> > <mailto: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 <mailto: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
> >> <mailto: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 <mailto: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
> >> <mailto: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
> >> <mailto:stambaughw@xxxxxxxxxxx>> wrote:
> >> >>
> >> >>> On 3/14/2014 5:32 PM, Marco Serantoni wrote:
> >> >>>>
> >> >>>> On 14/mar/2014, at 20:00, Wayne Stambaugh
> >> <stambaughw@xxxxxxxxxxx
> >> <mailto: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
> >> <mailto: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
> >> <mailto: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
> >> <mailto: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
> >> <mailto: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
>
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
-
Re: Local Variables
From: Marco Serantoni, 2014-03-17
-
Re: Local Variables
From: Marco Serantoni, 2014-03-17
-
Re: Local Variables
From: Wayne Stambaugh, 2014-03-17