← Back to team overview

kicad-developers team mailing list archive

Re: OSX Build changes.

 

Hi Bernhard.

Since BZR 5151, I cannot get any build of Kicad for OS X anymore.
As I deleted the executables, I am dead in the water.
I tried to build from your repository, and it does not build either.

What do you suggest as a build procedure from scratch?

I have deleted all the build directory trees I had, and I am ready to start again.
What do I need to check before trying to build?

I have wxwidget 3.0 installed with macports. Do I need to totally remove it?

Thanks for any help you will provide.

Jean-Paul
AC9GH




On Oct 2, 2014, at 3:58 PM, Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx> wrote:

> Yes, I didn’t do anything about documentation yet.
> It should be pretty easy to add if there is a way to copy/fetch/build it from CMake and put it to the bundle - just like the templates, etc.
> 
> Same for the libraries/footprints.
> Speaking about releases, maybe there should be two in future (build option for CMake, sth. like OSX_BUNDLE_INCLUDE_LIBMOD3D)… one with libraries, one without. I have all my libs/footprints/3d-models in my own local repository. I don’t care about wasting some bits and having default things in the bundle (if it doesn’t get too big), but I guess I don’t want them to show up and mix with my stuff.
> 
> I will (hopefully) fix scripting stuff at the weekend, I already made some first steps for that.
> Then, I found some ideas to try to place libraries in the right spot inside the bundle so that it will be more conform to Apple standards (as Garth noted previously - it will be only internal cosmetics, though).
> 
> I am open for above ideas then, if not anybody else already did it… I still have some other OSX things to provide (but need to be rebased first), e.g. I have some more eeschema redraw fixes that I think need to be included and I still have a patch open for more OSX-like X-Y touchpad scrolling (I couldn’t live without that one… :) ).
> 
> 
> Regards,
> Bernhard
> 
> On 02.10.2014, at 21:08, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
> 
>> The component and 3D model libraries are a good idea.  If the user
>> doesn't like the github plugin, then you could also include the
>> footprint libraries.  One thing I didn't see in Bernhard's patch was the
>> Documentation.  That is definitely a must at some point in order to have
>> a stable release.  I figure one step at time and we'll get there.  I
>> think this is a good first step.
>> 
>> 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
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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