Attempt at fixing build for FreeBSD

[GoogleCodeExporter]

Hi there,

This is a patch against r895 that does a few rough and ready changes to make 
the build pass on FreeBSD (tested with FreeBSD 9.2-RC4 with libc++ support 
compiled in, and the invocation `configure; env CXX=clang++ 
CXXFLAGS="-std=c++11 -stdlib=libc++" gmake`).  It's mainly written from the PoV 
of someone trying to make the build work rather than being "production-ready" 
(sorry!)

I haven't yet tested this to ensure it doesn't break the general case (I'm 
submitting it more as a pointer of things that need considering rather than an 
apply-and-be-done-with patch I'm afraid).

Highlights of what I've tried to do:

1) Change the shebang of configure from #!/bin/bash to #!/bin/sh.  This is 
because configure doesn't use any bashisms at all, and also because bash is 
located elsewhere on a FreeBSD box (/usr/local/bin/bash).  IMO it's definitely 
better to use the more portable shell here.

2) FreeBSD date does not support the -ud invocation.  In order to convert one 
date to another, one has to use the FreeBSD-specific -j -f invocation and also 
provide the source format.  Naturally, GNU date doesn't support -j -f!  I've 
filled in the svn date checker with the FreeBSD equivalent but didn't get 
around to doing it for other VCSes.  To be honest a more portable way of doing 
this would be better (not sure how one would without dragging in dependencies 
or needing to compile some C)

3) Prefix for includes and libraries is now a !!VARIABLE!! that can be changed 
by configure, currently this is set to /usr/local for FreeBSD and /usr for 
other systems.  Otherwise, things tend not to be found on the former (most user 
installed software and libraries go to /usr/local there) =P  Could be done 
better, really.

4) CXX is now overridable and many other Makefile variables are now appended to 
the environment, so that it's easier to specify different cxxflags and a 
different compiler (necessary for building with clang/libc++).

5) FreeBSD doesn't use the GNU version of flex, so it doesn't support the long 
version of -o, hence I've shortened that flag.

6) I added a recursive call to the rcdgen Makefile in the main Makefile, to 
make it build rcdgen that way instead of automatically trying to infer that it 
comes from rcdgen.cpp in the main Makefile.  This is somewhat magic and can 
probably be done better, but it was an issue I was having.

7) For some reason scanner_funcs.h wasn't picking up stdafx.h so I made this 
explicit.

The takeaway from this patch is generally that there are a surprising amount of 
portability issues to consider even from one Unix-like environment to another.  
I'd like to contribute to freerct but since I'm more a FreeBSD person than a 
Linux one I thought I'd try to get some of them cleared up if possible first!

~ Matt

PS: I know it isn't my position to say this, and that they suck horrifically 
(especially GNU autotools, ick), but I'd say considering a makefile generator 
might be a good idea?  I'm just saying this because I know that even what I've 
done to configure to make it work for just one more special case has brought in 
a lot of unmaintainability and complexity that probably isn't needed >=P

Original issue reported on code.google.com by mbw...@york.ac.uk on 14 Oct 2013 at 11:29

Attachments:

• freebsd.patch

[GoogleCodeExporter]

A pic i got sent, as proof :) http://snip.so/VpXk

Original comment by CharlesP...@googlemail.com on 14 Oct 2013 at 11:41

[GoogleCodeExporter]

I also wonder if instead of fiddling around with the date format inside 
find_version(), perhaps there should be a separate function, determining 'type' 
of date function to use

Original comment by CharlesP...@googlemail.com on 14 Oct 2013 at 11:45

[GoogleCodeExporter]

Most of this stuff has been implemented in a roundabout way, so i'll mark this 
as closed.
compilers still need some work though

Original comment by CharlesP...@googlemail.com on 19 Oct 2013 at 1:00

• Changed state: Fixed