Some OSX questions

[JamesF]

My planetary capture application, oacapture, is a mixture of C++ and C and uses a number of open source packages including Qt, ffmpeg and libusb.  Basically it's stuff that appears to be outside Apple's normal Cocoa framework etc.  At the moment I'm installing these packages from www.macports.org.

When I get around to packaging everything up for people to try on OSX I really don't want to bundle all of these packages, especially as some people may have them installed already, nor do I want to static link an executable against lots of large external libraries.

Is there a nicer way to deal this than to tell people they need to install a pile of stuff from macports?  Is there a more "preferred" source than macports?  I know there are quite a few repositories of open source packages out there.

James

[knobby]

http://brew.sh/ don't know much about this but seems to be similar to macports

[JamesF]

http://brew.sh/ don't know much about this but seems to be similar to macports

That is one of the other ones I've been looking at, though I am more inclined towards macports at the moment I have to say.

[knobby]

I think Macports seems... Safer, doesn't it put the packages somewhere that's easy to find / remove if problematic?

[JamesF]

Everything goes under /opt/local, yes, so it's probably easy to wipe it all out later if you wish to.

James

[JohnC64]

I've used (home)brew and its very good.  It also puts its resources in a central repository (/usr/local/cellar)  and has commands for un/installing.  brew install < package-name>, brew uninstall- <package name>.  It is ruby based and  you can add your own formula.

Installed libs
Downside  with using installed libs is that you can never be sure that the end user will have the exact same configuration of libs  that you have done your testing on.

Upside is that your app is lightweight

Static linked libs

Upside is that you have a compete self contained and tested solution.  Downside is it has a bit of bloat.

It is a tricky one to balance, especially if going down the multiplatform route
Cheers John

 

[themaninthesuitcase]

I've used both macports and homebrew.  Personally I prefer homebrew as I find it easier to use.

As for your problem, I'd rather be supplied the libs and know it will work even if that means I actually have several copies installed. SQLite will probably be on your machine dozens of times for example as a lot of applications use it for internal settings and save files etc.

[JamesF]

As for your problem, I'd rather be supplied the libs and know it will work even if that means I actually have several copies installed. SQLite will probably be on your machine dozens of times for example as a lot of applications use it for internal settings and save files etc.

Thus entirely defeating the purpose of shared objects/dynamic libraries to start with

James

[riklaunim]

Usually it's all included. I played some time ago with freezing PyQt4 applications on OSX and just like on Windows it has to have a copy of everything needed to work to be stand-alone installable application (unless you make some dependencies installable during app install - but that's rather "system" libraries on Windows, like some .NET framework stuff).

[cgarry]

When I finally complete the OS X version of PIPP I shall be including a copy of the required FFmpeg and Qt libraries with the install.  I don't think users can be bothered to install bits and pieces from here, there and everywhere to save a few MB of hard drive space, they expect an install to just work.

Cheers,

Chris

[NickK]

First rule of OSX programming - forget every other rational development idea

1. The user expects no, demands, no throws their toys out of the pram if it doesn't "Boom, it just works!" ©Jobs..

2. In lie of point 1, it doesn't matter if it's big, bloaty (except if it prevents rule 1) or not backward compatible with a PowerPC (see rule 1).. 

3. Never use /opt/... or /usr/.… etc.. or most of the stuff will stop working or get security issues in later OSX.. 

The point here is that Apple users expect it to work, they have no interest in managing things, installing MacPorts, debugging MacPorts/other… also the use of the latest Xcode prevents developing of 10.6.8 32 bit for example.. but I can say that most of the Apple users use 10.6.8.. it is getting to the end of it's useful life but it is still the mainstay for astro..

With that in mind, I'd use the private applications Frameworks directory for the dynamic libraries and use the install_tool to adjust the /usr/lib/.… search paths that will fail on OSX.. to something that uses @rpath or loader_path instead, I have a run script build phase on my legacy driver framework to change the search path in the included FTDI dynamic library:

install_name_tool -id "@rpath/../Frameworks/libftd2xx.1.2.2.dylib" libftd2xx.1.2.2.dylib

The you'll need to set up the app to look in the app bundle Frameworks directory.. job done.. test etc and you shouldn't have a support nightmare with the standard OSX install..

[themaninthesuitcase]

Thus entirely defeating the purpose of shared objects/dynamic libraries to start with

James

Whilst the idea of shared libs is lovely it still can bite you in the Bottom. I develop software for a living and it's still easier to deploy the same 4 core DLLs in every app than it is to much about with the GAC or proper system shared libs.  And that's in an environment I can control!

[JamesF]

Whilst the idea of shared libs is lovely it still can bite you in the Bottom. I develop software for a living and it's still easier to deploy the same 4 core DLLs in every app than it is to much about with the GAC or proper system shared libs.  And that's in an environment I can control!

It all seems a bizarre way to go about things to me, but I am from a UNIX/Linux development background which perhaps engenders a different mindset.

James

[JamesF]

Well.  I have looked at this a bit more.  It's surprising how fast you can get to not give a stuff about Mac users

James

[NickK]

Well.  I have looked at this a bit more.  It's surprising how fast you can get to not give a stuff about Mac users

James

Lol.

I would say demanding.. but toys and prams seems more accurate  and if you attempt to argue.. you will be condemned by going against the dead almighty.. 

[JamesF]

Is there a way to create all the necessary gubbins for a framework so the necessary shared libraries can just be dropped in if you're not using the Xcode IDE?  All the instructions I've been able to find thus far seem to assume its use.

James

[NickK]

Is there a way to create all the necessary gubbins for a framework so the necessary shared libraries can just be dropped in if you're not using the Xcode IDE?  All the instructions I've been able to find thus far seem to assume its use.

James

Xcode uses command line tools behind the scenes - so it's command line options that are being used. If you compile with Xcode - then you'll get the command line build as part of the output. You could use that as the steps for a build script.

There are two steps - both command line:

1. The linked library needs to be built/adjusted not to use /usr/lib etc as the default path..

2. The app needs to be built so it knows to search in the Bundle's Framework directory

Unfortunately - Xcode is the defacto Apple environment so 99.99% of the examples will be given in the form of how todo this in Xcode. A bundle is simply a set of files in a directory.. Xcode makes the construction a "simple" experience.