kicad-developers team mailing list archive

[Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>]

Hi Adam,

it’s already on Wayne’s desk to commit…


Regards,
Bernhard

On 02.10.2014, at 20:37, Adam Wolf <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> wrote:
> Hi Garth,
> 
> see below.
> 
> 
> Regards,
> Bernhard
> 
> On 02.10.2014, at 18:23, Garth Corral <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
>> 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