5 ms·

I have a hard time being overly sympathetic here. complaining about building from source and can't get profiling tools running? Building code is being a develop

by hnriot 14y ago

I have a hard time being overly sympathetic here. complaining about building from source and can't get profiling tools running? Building code is being a developer, and osx is no different that any other unix variant, it has its own toolsets, like dtruss, shark etc. I don't get why gprof doesn't work for you, it works fine for me on osx. this just seems like a lot of whining. If I wanted to debug a process that would occasionally get into a tight loop I'd run it under the debugger and break into it when it was peaking on the watt meter. A developer isn't just a programmer, the difference is that a developer can program and work the system, use the tools, debug the code, tune the kernel, etc etc.

dchichkov 14y ago
It's just that on Linux open source development tools [and libraries] work out of the box. Sudo apt-get, and you are in business. Not the case on Macs. Apple tend to break things with every xcode/clang release. And things tend to stay broken.
- ryannielsen 14y ago
  I'd love to see citations on clang bugs that persist without good reason (e.g. clang's adhering more closely to a standard, or refuses to implement a rarely used gcc extension).
  - dchichkov 14y ago
    Well, aside from clang + boost + mac monstrosity [there is always something wrong with boost + clang + mac], I haven't seen any persistent problems with clang itself. It's just that configure+build on mac is often a time sink... You try a default ./configure - it picks up legacy gcc4.2. Fail. You try forcing it to clang - there is something wrong with the switches/defines/gcc exts/etc. Easy to fix. But still sinks time :(
jedbrown 14y ago
If Apple cared about developers writing low-level code, they would pay one developer to make sure that Valgrind, debuggers, and the like worked out of the box.
- ryannielsen 14y ago
  Or they have other tools that they feel are as good or better. e.g. Instruments, clang, dtrace. Valgrind is powerful, and it would be nice if it was perfectly supported on OS X, but it's not the end-all-be-all of runtime analysis and profiling. And have you hit any issues with gdb that can be attributed to Apple's negligence? I think Apple's investment in clang, lldb and lld demonstrate they feel it's worth investing time and resources in having outstanding low-level development tools.
- pi18n 14y ago
  Maybe not, because they cannot seem to get Xcode working right all the time.
to3m 14y ago
It seemed more like warning than whining, if indeed it's any more than a simple story of something vaguely surprising to the author. There is no need for blog posts to be interesting or momentous, only well-written. And "Mac OS X is like Unix, but some of the familiar Unix-like tools don't work" seems like a useful enough warning to me. After all, who wants to learn new tools? Nobody who has something to actually do...
- adestefan 14y ago
  That line is incorrect. They author should have stated that "Mac OS X is like Linux, but some of the familiar Linux tools don't work."
  - jonhohle 14y ago
    Or, "Mac OS X _is_ UNIX, so all of the familiar UNIX tools work, but Linux is _like_ UNIX, so many of the familiar tools work differently." Where differently is generally a superset.
jdpage 14y ago
I've had issues with gprof and gcov. In particular, gcov doesn't seem to pick up functions called via function pointer on OSX, a task which it does fine on Linux. As someone doing somewhat Serious C Development, I'm beginning to come to the conclusion that while OSX might be a good platform for developing higher-level languages, the C support just isn't there in the way I need it to be, which is quite ironic really.
- adestefan 14y ago
  Because you shouldn't be using gcc on a modern (post full 64-bit transition) OS X system. The llvm/clang/dtrace toolset is far superior. Honestly, the gcc tools were never that great. On Sun systems, the Sun Studio set was always far superior and the other vendors had their own equivalents. Linux has just been "stuck" with gcc and the related Gnu tools since no one ever made anything better.
  - binarycrusader 14y ago
    And many people don't realize that Oracle Studio is available for Linux as well.
FooBarWidget 14y ago
> Building code is being a developer I want to build my code, not other people's code. I just want to use the tools, not spending lots of time making them work. Why do you think people buy Macs in the first place? > and osx is no different that any other unix variant, it has its own toolsets, like dtruss, shark etc. Except that Unix variants can be extremely different once you go beyond the basics (shell, cd, ls, cat, grep). Kernel interfaces, package managers, directory structures, dynamic linkers, authentication. "No different than any other unix variant" makes no sense.
- adestefan 14y ago
  The point is that it's "no different than any other unix variant" in that none of them share a common toolset once you get beyond the basics. Go and try to develop on AIX or HP/UX with your Linux knowledge and you won't get very far.
  - jonhohle 14y ago
    Learning, and forcing yourself to rely on the POSIX subset of utilities and libraries makes it significantly easier to not care which Unix-like operating system you're using.
    - pjmlp 14y ago
      Except that POSIX like all standards, has a tendency to have different quirks across implementations.
- i386 14y ago
  Most of these ports are maintained by volunteers. Would you pay for working tools?
- saurik 14y ago
  > Why do you think people buy Macs in the first place? I feel like the answer you are expecting to this question is also incongruous with the argument you are making: the Mac is not a platform for developers... if you want to spend less time messing around with software and have everything "just work", as a developer, you should be using a Linux distribution such as Ubuntu, not Mac OS X. Different systems make different tradeoffs in simplicity, and Mac OS X is simply not optimizing for you: you probably shouldn't have bought a Mac "in the first place" if you expected to do a lot of development on your local system (unless, of course, you like messing around getting all of your tools working; some people surely do ;P). Seriously: even installing something as basic as "gcc" is awkward (bunch of graphical steps to download gigabytes of stuff you didn't need, or a mysterious path through a website to get just command line tools, and in the end you have an ancient version anyway (or Clang, which isn't always going to compile whatever random other libraries or code you need to work with).

by hnriot 14y ago

dchichkov 14y ago

It's just that on Linux open source development tools [and libraries] work out of the box. Sudo apt-get, and you are in business. Not the case on Macs. Apple tend to break things with every xcode/clang release. And things tend to stay broken.

ryannielsen 14y ago
I'd love to see citations on clang bugs that persist without good reason (e.g. clang's adhering more closely to a standard, or refuses to implement a rarely used gcc extension).
- dchichkov 14y ago
  Well, aside from clang + boost + mac monstrosity [there is always something wrong with boost + clang + mac], I haven't seen any persistent problems with clang itself. It's just that configure+build on mac is often a time sink... You try a default ./configure - it picks up legacy gcc4.2. Fail. You try forcing it to clang - there is something wrong with the switches/defines/gcc exts/etc. Easy to fix. But still sinks time :(

jedbrown 14y ago

If Apple cared about developers writing low-level code, they would pay one developer to make sure that Valgrind, debuggers, and the like worked out of the box.

ryannielsen 14y ago
Or they have other tools that they feel are as good or better. e.g. Instruments, clang, dtrace. Valgrind is powerful, and it would be nice if it was perfectly supported on OS X, but it's not the end-all-be-all of runtime analysis and profiling. And have you hit any issues with gdb that can be attributed to Apple's negligence? I think Apple's investment in clang, lldb and lld demonstrate they feel it's worth investing time and resources in having outstanding low-level development tools.
pi18n 14y ago
Maybe not, because they cannot seem to get Xcode working right all the time.

to3m 14y ago

It seemed more like warning than whining, if indeed it's any more than a simple story of something vaguely surprising to the author. There is no need for blog posts to be interesting or momentous, only well-written. And "Mac OS X is like Unix, but some of the familiar Unix-like tools don't work" seems like a useful enough warning to me. After all, who wants to learn new tools? Nobody who has something to actually do...

adestefan 14y ago
That line is incorrect. They author should have stated that "Mac OS X is like Linux, but some of the familiar Linux tools don't work."
- jonhohle 14y ago
  Or, "Mac OS X _is_ UNIX, so all of the familiar UNIX tools work, but Linux is _like_ UNIX, so many of the familiar tools work differently." Where differently is generally a superset.

jdpage 14y ago

I've had issues with gprof and gcov. In particular, gcov doesn't seem to pick up functions called via function pointer on OSX, a task which it does fine on Linux. As someone doing somewhat Serious C Development, I'm beginning to come to the conclusion that while OSX might be a good platform for developing higher-level languages, the C support just isn't there in the way I need it to be, which is quite ironic really.

adestefan 14y ago
Because you shouldn't be using gcc on a modern (post full 64-bit transition) OS X system. The llvm/clang/dtrace toolset is far superior. Honestly, the gcc tools were never that great. On Sun systems, the Sun Studio set was always far superior and the other vendors had their own equivalents. Linux has just been "stuck" with gcc and the related Gnu tools since no one ever made anything better.
- binarycrusader 14y ago
  And many people don't realize that Oracle Studio is available for Linux as well.

FooBarWidget 14y ago

> Building code is being a developer I want to build my code, not other people's code. I just want to use the tools, not spending lots of time making them work. Why do you think people buy Macs in the first place? > and osx is no different that any other unix variant, it has its own toolsets, like dtruss, shark etc. Except that Unix variants can be extremely different once you go beyond the basics (shell, cd, ls, cat, grep). Kernel interfaces, package managers, directory structures, dynamic linkers, authentication. "No different than any other unix variant" makes no sense.

adestefan 14y ago
The point is that it's "no different than any other unix variant" in that none of them share a common toolset once you get beyond the basics. Go and try to develop on AIX or HP/UX with your Linux knowledge and you won't get very far.
- jonhohle 14y ago
  Learning, and forcing yourself to rely on the POSIX subset of utilities and libraries makes it significantly easier to not care which Unix-like operating system you're using.
  - pjmlp 14y ago
    Except that POSIX like all standards, has a tendency to have different quirks across implementations.
i386 14y ago
Most of these ports are maintained by volunteers. Would you pay for working tools?
saurik 14y ago
> Why do you think people buy Macs in the first place? I feel like the answer you are expecting to this question is also incongruous with the argument you are making: the Mac is not a platform for developers... if you want to spend less time messing around with software and have everything "just work", as a developer, you should be using a Linux distribution such as Ubuntu, not Mac OS X. Different systems make different tradeoffs in simplicity, and Mac OS X is simply not optimizing for you: you probably shouldn't have bought a Mac "in the first place" if you expected to do a lot of development on your local system (unless, of course, you like messing around getting all of your tools working; some people surely do ;P). Seriously: even installing something as basic as "gcc" is awkward (bunch of graphical steps to download gigabytes of stuff you didn't need, or a mysterious path through a website to get just command line tools, and in the end you have an ancient version anyway (or Clang, which isn't always going to compile whatever random other libraries or code you need to work with).