The libX dylibs are not needed. The library dependencies can and should be built without X. If the kicad binaries are not 2-way fat then there’s no reason the bundled libs should be either.
Garth > On Feb 28, 2015, at 3:18 PM, Marco Serantoni <marco.serant...@gmail.com> > wrote: > > Wayne, > At the time we were in a timeframe where was ppc finishing his fading out, > i386 in mid term, x86_64 was not already fully adopted. > KiFace work begin was forcing a migration from the old default behavior of > static linking to dynamic. > Now: > i386 fading/faded out completely. > The linking is dynamic. > All bundles are collapsed to a single one after KiFace become complete. > > So i386 could be desupported, the issue of multiple copies of dynamic > libraries for each bundle, as planned, is no more needed too. > I personally think that also Phyton could be now migrated to 2.7 and no more > 2.6 (other legacy from the platforms above). > > Much of that work is now obsolete. > Guys has done a great job with the new disto. > > I’ve a couple of question for them: > * Are libX*.dynlib really needed ? > * Since binaries are x86_64, do you think isn’t the case to use “lipo > -remove” for unneeded architecture from all dynlibs? > > Great job! > > — > Marco > >> On 25/feb/2015, at 22:52, Wayne Stambaugh <stambau...@gmail.com> wrote: >> >> I'm surprised it still works with all of the changes made for the OSX >> bundle support. I'll leave it as is for the upcoming stable release. >> Please take note that one of the first things I'm going to do after the >> stable release is remove all of the download_foo code from the kicad >> build system. This code should have always been maintained outside the >> kicad source tree as a stand alone project or projects if you would >> prefer one project per dependency. Everyone has plenty of warning so if >> you depend on this to build dependencies on your platform, now is the >> time to start working on what ever dependency builders you need. >> >> On 2/25/2015 1:47 PM, Garth Corral wrote: >>> I do use it but I'm not opposed to removing it if that's what you want. >>> It does still seem to work and is convenient if you don't want to use >>> installed dependencies. I can just as easily move that to a script, though. >>> >>> Garth >>> >>> On Feb 25, 2015, at 10:30 AM, Bernhard Stegmaier >>> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>> wrote: >>> >>>> No, I didn’t use it since the app bundle updates. >>>> I even don’t know if it still works with all the changes since. >>>> >>>> >>>> Regards, >>>> Bernhard >>>> >>>>> On 25 Feb 2015, at 18:47, Adam Wolf <adamw...@feelslikeburning.com >>>>> <mailto:adamw...@feelslikeburning.com>> wrote: >>>>> >>>>> The nightlies do not. >>>>> >>>>> Adam Wolf >>>>> >>>>> On Wed, Feb 25, 2015 at 11:29 AM, Wayne Stambaugh >>>>> <stambau...@gmail.com <mailto:stambau...@gmail.com>> wrote: >>>>> >>>>> Is anyone still using the old USE_OSX_DEPS_BUILDER? If not, I think >>>>> it's time to remove it from CMakeLists.txt. >>>>> >>>>> Cheers, >>>>> >>>>> Wayne > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
