kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

It's committed!  Many thanks to Bernhard for taking on the task of
fixing the OSX builds.  Hopefully he can get the scripting working soon.
 Once that is done, adding the documentation and libraries should be a
piece of cake :)  He also graciously updated the OSX build instructions
so hopefully others can help out with the testing.  This should get us
one step closer to providing regular OSX builds for testing.

Wayne

On 10/2/2014 2:52 PM, Adam Wolf wrote:
> No problem--I certainly can't look at it until Saturday or Sunday, but
> I'm seriously very excited about this!
> 
> When I pointed a few users at the bundle, they said "Where are the
> libraries?"
> 
> I will probably look at what the damage would be to pull in the Github
> libraries into the bundle and point the tools at it, unless someone has
> already started.
> 
> Adam Wolf
> 
> Ad
> 
> On Oct 2, 2014 1:45 PM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx
> <mailto:stambaughw@xxxxxxxxxxx>> wrote:
> 
>     Sorry guys.  I got sidetracked last night with some 3D stuff and I
>     didn't get it committed.  I've already tested to make sure it didn't
>     break windows or linux builds so it's ready to commit.  I will do my
>     best to get it committed this evening when I get home from work.
> 
>     Wayne
> 
>     On 10/2/2014 2:38 PM, Bernhard Stegmaier wrote:
>     > Hi Adam,
>     >
>     > it’s already on Wayne’s desk to commit…
>     >
>     >
>     > Regards,
>     > Bernhard
>     >
>     > On 02.10.2014, at 20:37, Adam Wolf <adamwwolf@xxxxxxxxx
>     <mailto:adamwwolf@xxxxxxxxx>
>     > <mailto:adamwwolf@xxxxxxxxx <mailto:adamwwolf@xxxxxxxxx>>> wrote:
>     >
>     >> Hi Bernhard,
>     >>
>     >> Sorry to threadjack, but do you have any ETA on the patch that
>     created
>     >> that bundle?  I'm extremely excited to release nightlies...
>     >>
>     >> Adam Wolf
>     >> Cofounder and Engineer
>     >> Wayne and Layne LLC
>     >>
>     >> On Oct 2, 2014 1:29 PM, "Bernhard Stegmaier"
>     <stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx>
>     >> <mailto:stegmaier@xxxxxxxxxxxxx
>     <mailto:stegmaier@xxxxxxxxxxxxx>>> wrote:
>     >>
>     >>     Hi Garth,
>     >>
>     >>     see below.
>     >>
>     >>
>     >>     Regards,
>     >>     Bernhard
>     >>
>     >>     On 02.10.2014, at 18:23, Garth Corral <gcorral@xxxxxxxxx
>     <mailto:gcorral@xxxxxxxxx>
>     >>     <mailto:gcorral@xxxxxxxxx <mailto:gcorral@xxxxxxxxx>>> wrote:
>     >>
>     >>>     Hi Bernhard,
>     >>>
>     >>>     I looked around through the application bundle you posted
>     and had
>     >>>     some questions about the proposed layout.  It seems there is
>     some
>     >>>     arbitrary placement of files in the bundle.  I know it
>     ultimately
>     >>>     doesn’t matter to most users as long as it runs and behaves
>     >>>     properly but it doesn’t really follow the usual guidelines for
>     >>>     layout.
>     >>     Well… it is like CMake BundleUtilities do it out of the box. I
>     >>     didn’t implement that.
>     >>
>     >>>     Is there any chance that the dylibs could not be dumped in the
>     >>>     MacOS directory?  They really don’t belong there, as is the case
>     >>>     for most everything in there.  I think these should be in a
>     >>>     Frameworks directory at the very least.  Also, and this is
>     just a
>     >>>     point of curiosity, but why is libX11 included in these
>     >>>     libraries?  What requires that to run?
>     >>     I will check that. There is one parameter for CMake’s
>     >>     fixup_bundle() that might do the trick, but it is not really
>     >>     documented.
>     >>     I will have to check the code what it does exactly and if/how it
>     >>     could be changed.
>     >>     BundleUtilities just include what is not standard. Obviously the
>     >>     cairo which got picked up was built by MacPorts and has some
>     >>     transitive dependencies to the libX11 also built by MacPorts
>     - all
>     >>     the libs that are in the bundle come from my /opt/local
>     folder, so
>     >>     this is fine. Things may be different with other setups.
>     >>
>     >>>     Same for the command line binaries, they are things that are not
>     >>>     required for the application to run so belong out in a support
>     >>>     directory of some kind.
>     >>     I also thought about not putting them into the bundle at all, but
>     >>     I did because it doesn’t hurt and some people might still use
>     them
>     >>     directly.
>     >>     The command line binaries of .kiface applications must be in the
>     >>     same folder as the .kiface - or you again have to link stuff.
>     >>
>     >>>     I’m not familiar with the kiface files, but they appear to be
>     >>>     loadable bundles, which also don’t belong there.  Probably
>     belong
>     >>>     in a PlugIns directory
>     >>     Yes, maybe… but the same as above. As it is currently implemented
>     >>     they must be in the same folder as the main kicad application,
>     >>     otherwise they won’t be loaded.
>     >>
>     >>>     It looks like the remainder of the applications are in there as
>     >>>     well, albeit not integrated into application bundles themselves.
>     >>>     Not really sure how those should be integrated, but putting
>     their
>     >>>     pieces in the MacOS directory doesn’t seem ideal.  Any chance
>     >>>     these applications could just be consumed whole in an
>     >>>     Applications directory inside the main app?  Apple does this for
>     >>>     some of their own applications.  It doesn’t provide much in the
>     >>>     way of additional functionality but it does allow things to be
>     >>>     organized in a cleaner way, and as a side effect the
>     applications
>     >>>     could still be run standalone in a pinch.
>     >>     Well, yes, maybe it is not ideal to have the idf* tools in there.
>     >>     But, at least they are there and can be used. Some other project
>     >>     like for example Calibre also just put them into the bundle
>     as I did.
>     >>     Normally, that stuff probably should go directly to the
>     >>     filesystem, but then you have to write an installer, or some
>     >>     script that does copying.
>     >>
>     >>>     Obviously the intent going forward is to have only the one main
>     >>>     application, but it doesn’t seem like the current structure of
>     >>>     the project is quite there yet.
>     >>     The main intent was to *not* bundle all dependencies in *every*
>     >>     individual bundle for pcbnew, eeschema, etc. as it was before and
>     >>     to remove the dependencies between the bundles that were imposed
>     >>     by symlinks to the kifaces.
>     >>     Further, also one main intent was to use default tools to create
>     >>     the bundle like CMake’s BundleUtilities.
>     >>
>     >>>     Anyway, I know that not all applications follow the model,
>     but it
>     >>>     seems like it would be good to try to lay things out in as
>     >>>     standard a way as possible, accounting for application needs, of
>     >>>     course.
>     >>     You’re welcome to continue my work and make the internals more
>     >>     Apple-like - this would probably impose some more changes not
>     only
>     >>     to build process, but also the code.
>     >>     For me, it’s more important that an application behaves and feels
>     >>     more OSX like from a users point of view than to have every
>     >>     internal thing the right way Apple said it had to be.
>     >>
>     >>>     Here’s Apple’s guidelines.  Again, I know not everything fits.
>     >>>
>     >>>   
>      https://developer.apple.com/library/ios/documentation/CoreFoundation/Conceptual/CFBundles
>     >>>
>     >>>     Garth
>     >>>>     Hi all,
>     >>>>
>     >>>>     as Wayne already mentioned below I made some major changes
>     to the creation of OSX application bundles in the build process.
>     >>>>     The most obvious is that now only one application bundle is
>     created which starts the kicad launcher.
>     >>>>     From there you can go anywhere else.
>     >>>>     The created bundle now is (should be) completely
>     relocatable, so you can just put it anywhere you want as with other
>     OSX apps.
>     >>>>     All the pre-delivered templates, etc. have been moved into
>     the bundle and should be found from there.
>     >>>>     Command-Line tools are still contained (and accessible via
>     e.g. /Applications/kicad.app/Contents/MacOS/idf…).
>     >>>>
>     >>>>     I have uploaded a sample dmg image here:
>     >>>>       http://ul.to/ypsk7m41
>     >>>>     What you see in the dmg is 1:1 what is created in the build
>     process now… this should make packaging and distributing automated
>     builds very easy in future.
>     >>>>
>     >>>>     I am still doing some final touches to the patch before it
>     gets submitted.
>     >>>>     So, feel free to test and comment…
>     >>>>
>     >>>>
>     >>>>     Regards,
>     >>>>     Bernhard
>     >>>
>     >>>     _______________________________________________
>     >>>     Mailing list: https://launchpad.net/~kicad-developers
>     >>>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >>>     <mailto: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>
>     >>     <mailto: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
>