Comment #0 by boucher.travis — 2009-11-19T17:09:37Z
Created attachment 502
Quick fix for freebsd.mak
Issues look to be related to the linux.mak file being kept up to date with
source changes, but the freebsd.mak not being.
When compiling, first dwarf.c complains about not finding mars.h. This is
fixed in the linux.make by adding -I. to the c flags.
When linking, complains about missing symbols related to json, the freebsd.mak
doesn't even try to compile json.
Attached is a trivial patch which fixes the issues.
Since the fix was to just copy the linux.mak to freebsd.mak, then update the
CFLAGS and MFLAGS to change the TARGET_LINUX to TARGET_FREEBSD, the issue is
trivial.
A proper fix would be to create a generic Makefile (or posix.mak if you
prefer), and use another method of specifying the proper defines for the
specific OS.
GNU Make has rich string manipulation routines which would be used to parse
`uname`. However this adds the dependency of GNU Make (currently the makefile
works with BSD make, which is something I like).
Another option is to use the compiler defined macros, and use an 'os.h' or
similar file to define TARGET_LINUX, TARGET_FREEBSD, etc. This has the
advantage of not requiring too many modifications as new code is added to the
codebase and could even combine the windows makefile with the unix one
(possibly). The biggest disadvantage I can see in this method is os.h will be
one big mess (as most C pre-processor portability code is).
Other things I'd like to see is cleaning up the legacy mess of the mars
symlink. Quick & dirty fix would be to have the make file make the symlink
itself so the build process becomes: cd src && make
Comment #1 by boucher.travis — 2009-11-19T17:11:38Z
If the idea of a unified make file (for at least unix) is something that is wanted, I'd be glad to craft something up.