Does not install via homebrew for OS X

[gridsystem]

Firstly, I needed this fix as uname -r shows only the kernel version number on OS X:

inreplace 'common.mk', 'UNAME=$(shell uname -r)', 'UNAME=$(shell uname)'

Secondly, when installing with the following commands, make does not create the required directories (presumably assuming that /bin already exists) and fails.

system "make PREFIX=#{prefix}"
system "make install PREFIX=#{prefix}"

[mkilgore]

Sorry -- I don't run an OSX system so I can't test on it. There was someone else who got it working on OSX, I'm curious why we didn't run into these issues before.

I think it should actually beUNAME:=$(shell uname -s) -- That outputs the name of the kernel (Drawin for OSX, Linux for Linux based). That's what I check against anyway. A normal uname must end-up printing out the same information as a uname -s (It does on my system), but I'm not sure I'd want to rely on that functionality always being the same.

Does make and make install work fine if you make the directories by hand, or have you not tried? Creating those directories if they don't exist is trivial, I just want to make sure that's the only issue :)

I'll send in a patch to fix these issues later today, thanks for the report. If there are any other issues let me know.

[gridsystem]

Once I'd changed uname -r to unameI had no trouble doing a manual installation with your default prefix, which I'm using now. I really like it!

Where can I find the files which are installed so that I can clean up before reinstalling with the package manager?

[mkilgore]

Goad to hear that went well :)

Right now, there are only 3 files installed, you can see them listed out if you run make install, but I can just as easily list them here for now:

PREFIX/lib/libreddit.so
PREFIX/include/reddit.h
PREFIX/bin/creddit

Do you know of anything specific I should do to make it play nicer with homebrew? (That is, anything specific with installation rather then just running 'install' like I am now)

[gridsystem]

It's pretty simple, build arguments etc are probably something you'll understand far better than I. Some docs which might be worth a skim: the formula I've got furthest with, blank homebrew formula template, formula docs.

I'm happy to test again whenever the makefiles have been patched to create the directories.

[mkilgore]

It looks to me like your script there should be fine as long as I make that change to create /bin, /lib, and /include when needed. The PREFIX set should work as wanted, but I'll test it locally to make sure, I'm creating the patch right now.

[Cotix]

Hmm I just tested on OSX, and im getting errors too. Otherones though. I'm getting

src/main.c:726: error: unknown field ‘svalue’ specified in initializer
src/main.c:727: error: unknown field ‘svalue’ specified in initializer
src/main.c:728: error: unknown field ‘svalue’ specified in initializer

[mkilgore]

I'll look into this, is that the full compiler output? Also, any idea what compiler your using? (I assume gcc, but I'm using gcc 4.8.2 and master builds just fine). IIRC MacOSX is stuck with gcc version 4.2 (or something to that effect) because gcc switched over to GPL3. I've compiled the source with clang as the compiler with no issues as well (Version 3.3).

While it's nothing more then a guess, I have a feeling it may be the fact that struct optOption has a field like this (In ./src/opt.h):

union {
    struct {
        int ivalue;
    };
    struct {
        char svalue[OPT_STRLEN + 1];
    };
};

It might work if you remove the internal structs (They were useful at one point when writing the code, but they're actually pointless in the current code). So something like this:

union {
    int ivalue;
    char svalue[OPT_STRLEN + 1];
};

And at the moment, the union itself isn't even really useful, so you could take the union out as well and just stick the fields in directly. I think that version of gcc may not like anonymous structs and unions which then causes the error.

[pauldub]

@DSMan195276 Hello, I had the "svalue" compiler issue when building on Mac OSX.

Removing all the unions from the optOption struct did work for me.

[mkilgore]

Ok, sounds good then. Tonight (~11 hours or so) I'll send in a patch to simply remove the anonymous structs and unions from the optOption struct. I may put in a named union later, but at the moment keeping the union isn't really worth the trouble in my opinion.