Hi Adam, it’s already on Wayne’s desk to commit…
Regards, Bernhard On 02.10.2014, at 20:37, Adam Wolf <[email protected]> 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" <[email protected]> wrote: > Hi Garth, > > see below. > > > Regards, > Bernhard > > On 02.10.2014, at 18:23, Garth Corral <[email protected]> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
