3 ms·

1) You could also create some wrapper scripts setting the path, or have someting inspired by virtualenv handle it, or maybe different terminal profiles. Those b

by lloeki 15y ago

1) You could also create some wrapper scripts setting the path, or have someting inspired by virtualenv handle it, or maybe different terminal profiles. Those breakings really are edge cases. 2) Don't put them in the PATH. They're prefixed with 'g' so you can make an non-prefixed alias for your interactive shell, and use the prefixed variant in your scripts if need be. If you write portable scripts you're either using common features or use some vars for those utils, aren't you? 3) g++? that's not in homebrew... Honestly though, MacPorts is a real pain. That's why I worked with others to bring Arch's pacman on OSX (dubbed ArchOSX) some years ago, but binary hosting was proving being a chore, and then Homebrew started taking off, and in my case Just Works.

brown9-2 15y ago
I'm curious, what are some of the pains you've had with MacPorts? I've been using it for about 8 months with no real issues, but then again I'm not a C/C++/native developer.
- zbuc 15y ago
  I've had it fail to install packages for me before, forcing me to grab them from source, modify the source with patches, and compile by hand. I've been using Homebrew for about a year and haven't ever had an issue like that.
bad_user 15y ago
3) g++? that's not in homebrew... He probably meant GCC, which does have recipes in Homebrew. Homebrew started taking off, and in my case Just Works This is the first time I ever heard anyone saying it. In general Homebrew did a good job for me, but it did break on me a couple of times. And when it did, fixing it caused me a lot of stress, because in the end it's really not much better than "./configure && make && sudo make install". What I don't understand is how come we can't have binary repositories, like Debian's. Certainly Debian has to handle much more architectures and the number of packages contained is really huge. So how come there isn't such an alternative for Mac OS X? Why are solutions like Homebrew and MacPorts insisting on compiling the packages locally?
- adsr 15y ago
  I believe Fink provides binaries.
- pilif 15y ago
  If you are attached to binary packages, there's always fink which might even predate Macports. Unfortunately, building the packages and then keeping them current takes quite a bit of infrastructure which is why fink's binary packages are really outdated at times. The other issue is with runtime-dependencies: Self-compiling packages gives you the freedom to, say, build vim without X11 support. With binary packages, the maintainer (or the packaging system) must create n packages for n possible combinations (if the project doesn't have some dynamic-library based plugin system) which is, again problematic from a resource-requirement perspective.
  - vacri 15y ago
    That being said, if debian can do it for around 30,000 packages on almost as many architectures as OSX has mere hardware models, why can't OSX do it? With all the app stores and cloud services, Apple is big on 'quite a bit of infrastructure'.
    - semanticist 15y ago
      Because Apple don't provide these package management tools, volunteering third-parties do. Apple are never going to provide Linux-style package management tools because the market for them is minuscule compared to Apple's real market: normal people. For normal people, there's the App Store.
      - dlikhten 15y ago
        while I agree, the point is moot as this talks about developers. So yes, apple did not make a package management tool. That pisses developers off. Makes no difference because you suck it up if you want to develop for mac/ios. Its kind of like developing on windows, for windows, gota do what u gotta do.
      - 15y ago
CJefferson 15y ago
1) Well, I could do I suppose. That all sounds a bit complicated however. 2) I am not talking about my own scripts, I am talking about other peoples. I could obviously go through and debug them, and then check I haven't broken them on a couple of linuxes, and a mac without macports/homebrew but... I don't want to. 3) You are right, it looks like gcc and gdb have both been taken out of homebrew, I assume because they didn't work. They were there previously. Certainly I find homebrew very useful. Just now I noticed the one thing I used in fink in now in homebrew, so have removed fink which should also hopefully slove problems. However, as time goes by, I find the OSX is getting slowly worse. In the days of OS X 10.1, the various command line tools were in sync between linux and mac os x, and now that is certainly not true, and I find the linux set more useful, especially in a default state.
- lloeki 15y ago
  2) I am not talking about my own scripts, I am talking about other peoples. I could obviously go through and debug them, and then check I haven't broken them on a couple of linuxes, and a mac without macports/homebrew but... I don't want to. Which is why the alias solution is nice, as it will only impact the interactive shell, not the scripts.
mikemcquaid 15y ago
Homebrew does have binary packages (we call them bottles). I'm the guy who implemented the feature and I am realising that as I didn't shout very loudly people don't realise that it exists. For example Qt has a bottle: https://github.com/mxcl/homebrew/blob/master/Library/Formula/qt.rb https://github.com/mxcl/homebrew/blob/master/Library/Formula... The reason we aren't doing this for more packages is basically people power and hosting (as I'm not sure Sourceforge would be happy we hosting the number of binaries we'd want to have). Hope that explains a bit. Feel free to comment if you think we're taking a good/bad approach here.
- sciurus 15y ago
  Hundreds of organizations donate mirror space to linux distributions (e.g. http://www.debian.org/mirror/list http://www.debian.org/mirror/list). I'm sure some of them would provide space to homebrew.

by lloeki 15y ago

brown9-2 15y ago

I'm curious, what are some of the pains you've had with MacPorts? I've been using it for about 8 months with no real issues, but then again I'm not a C/C++/native developer.

zbuc 15y ago
I've had it fail to install packages for me before, forcing me to grab them from source, modify the source with patches, and compile by hand. I've been using Homebrew for about a year and haven't ever had an issue like that.

bad_user 15y ago

3) g++? that's not in homebrew... He probably meant GCC, which does have recipes in Homebrew. Homebrew started taking off, and in my case Just Works This is the first time I ever heard anyone saying it. In general Homebrew did a good job for me, but it did break on me a couple of times. And when it did, fixing it caused me a lot of stress, because in the end it's really not much better than "./configure && make && sudo make install". What I don't understand is how come we can't have binary repositories, like Debian's. Certainly Debian has to handle much more architectures and the number of packages contained is really huge. So how come there isn't such an alternative for Mac OS X? Why are solutions like Homebrew and MacPorts insisting on compiling the packages locally?

adsr 15y ago
I believe Fink provides binaries.
pilif 15y ago
If you are attached to binary packages, there's always fink which might even predate Macports. Unfortunately, building the packages and then keeping them current takes quite a bit of infrastructure which is why fink's binary packages are really outdated at times. The other issue is with runtime-dependencies: Self-compiling packages gives you the freedom to, say, build vim without X11 support. With binary packages, the maintainer (or the packaging system) must create n packages for n possible combinations (if the project doesn't have some dynamic-library based plugin system) which is, again problematic from a resource-requirement perspective.
- vacri 15y ago
  That being said, if debian can do it for around 30,000 packages on almost as many architectures as OSX has mere hardware models, why can't OSX do it? With all the app stores and cloud services, Apple is big on 'quite a bit of infrastructure'.
  - semanticist 15y ago
    Because Apple don't provide these package management tools, volunteering third-parties do. Apple are never going to provide Linux-style package management tools because the market for them is minuscule compared to Apple's real market: normal people. For normal people, there's the App Store.
    - dlikhten 15y ago
      while I agree, the point is moot as this talks about developers. So yes, apple did not make a package management tool. That pisses developers off. Makes no difference because you suck it up if you want to develop for mac/ios. Its kind of like developing on windows, for windows, gota do what u gotta do.
    - 15y ago

CJefferson 15y ago

1) Well, I could do I suppose. That all sounds a bit complicated however. 2) I am not talking about my own scripts, I am talking about other peoples. I could obviously go through and debug them, and then check I haven't broken them on a couple of linuxes, and a mac without macports/homebrew but... I don't want to. 3) You are right, it looks like gcc and gdb have both been taken out of homebrew, I assume because they didn't work. They were there previously. Certainly I find homebrew very useful. Just now I noticed the one thing I used in fink in now in homebrew, so have removed fink which should also hopefully slove problems. However, as time goes by, I find the OSX is getting slowly worse. In the days of OS X 10.1, the various command line tools were in sync between linux and mac os x, and now that is certainly not true, and I find the linux set more useful, especially in a default state.

lloeki 15y ago
2) I am not talking about my own scripts, I am talking about other peoples. I could obviously go through and debug them, and then check I haven't broken them on a couple of linuxes, and a mac without macports/homebrew but... I don't want to. Which is why the alias solution is nice, as it will only impact the interactive shell, not the scripts.

mikemcquaid 15y ago

Homebrew does have binary packages (we call them bottles). I'm the guy who implemented the feature and I am realising that as I didn't shout very loudly people don't realise that it exists. For example Qt has a bottle: https://github.com/mxcl/homebrew/blob/master/Library/Formula/qt.rb https://github.com/mxcl/homebrew/blob/master/Library/Formula... The reason we aren't doing this for more packages is basically people power and hosting (as I'm not sure Sourceforge would be happy we hosting the number of binaries we'd want to have). Hope that explains a bit. Feel free to comment if you think we're taking a good/bad approach here.

sciurus 15y ago
Hundreds of organizations donate mirror space to linux distributions (e.g. http://www.debian.org/mirror/list http://www.debian.org/mirror/list). I'm sure some of them would provide space to homebrew.