kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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