Eliminate the Mac OS warning

[waldoj]

I've tested this on two machines running Mac OS 10.11.3. As long as gcc is installed (via Xcode or otherwise), everything works fine. This disclaimer does not appear to be warranted.

[canihavesomecoffee]

This seems pointless to me. If anything changes in the future that breaks the current build command again, we'd have to add the warning again... Currently with the warning it's just pointing out that it might not work (untested and untestable for us), not that it's not working...

[waldoj]

It seems like there are four viable paths here, which I list in order of completeness:

1. Eliminate the warning, because anything might not work. That is the nature of software. Absent some evidence that CCExtractor frequently fails to compile on Mac OS, this warning seems unnecessary.
2. Retain the warning, but provide an explicit call to action (e.g., "provide the console output in a new ticket at https://github.com/CCExtractor/ccextractor/issues/new"), so that it will be unnecessary to describe it as being "not maintained."
3. Solicit a regular user of the software to test it on Mac OS. Given how widely used Mac OS is, I imagine this would be a straightforward proposal.
4. Automatically test commits on Travis CI, which can test on both Linux and Mac OS. This is free and easy to set up.

I am happy to assist with any of these. The current warning provides the false impression that CCExtractor is not likely to work on Mac OS. (This warning kept me from bothering with it for a long while.)

[cfsmp3]

CCExtractor compiles and runs on Mac because an effort is made for
portability. But it's not tested at all by developers (as opposed to the
linux and windows versions) - it just happens to work, but very often the
build script will break due to a missing dependency.

If you want to become an official maintainer of the Mac stuff I'll be happy
to remove that warning.

There's some Mac stuff (a OSX GUI comes to mind) that we have ready but not
released as part of the general release because we cannot maintain it
properly.

On Wed, Feb 3, 2016 at 4:23 PM, Waldo Jaquith notifications@github.com
wrote:

It seems like there are four viable paths here, which I list in order of
completeness:

1. Eliminate the warning, because anything might not work. That is
   the nature of software. Absent some evidence that CCExtractor frequently
   fails to compile on Mac OS, this warning seems unnecessary.
2. Retain the warning, but provide an explicit call to action (e.g.,
   "provide the console output in a new ticket at
   https://github.com/CCExtractor/ccextractor/issues/new"), so that it
   will be unnecessary to describe it as being "not maintained."
3. Solicit a regular user of the software to test it on Mac OS. Given
   how widely used Mac OS is, I imagine this would be a straightforward
   proposal.
4. Automatically test commits on Travis CI, which can test on both
   Linux and Mac OS. This is free and easy to set up.

I am happy to assist with any of these. The current warning provides the
false impression that CCExtractor is not likely to work on Mac OS. (This
warning kept me from bothering with it for a long while.)

—
Reply to this email directly or view it on GitHub
#275 (comment)
.

[waldoj]

If you want to become an official maintainer of the Mac stuff I'll be happy
to remove that warning.

I don't have the knowledge to maintain a Mac build script (I haven't written any C for over 20 years)—I can only tell you if the build works. But I'd be happy to create a Travis CI test, so that you can know automatically whether the build is broken on Mac OS.

[cfsmp3]

On Wed, Feb 3, 2016 at 8:08 PM, Waldo Jaquith notifications@github.com
wrote:

I don't have the knowledge to maintain a Mac build script (I haven't
written any C for over 20 years)—I can only tell you if the build works.
But I'd be happy to create a Travis CI test, so that you can know
automatically whether the build is broken on Mac OS.

—

The script is just a one liner bash script - take a look. What we do each
time is whatever is missing from the linux script (usually a new directory
or library dependency) we copy to the Mac script and hope for the best. So
far so good.

[waldoj]

Oh, I'm quite happy to monitor it, I just mean that if it breaks, I'm probably of no help fixing it. :)