Summary: DMD won't compile on FreeBSD (freebsd.mak doesn't seem
to be maintained)
--- Comment #0 from Travis Boucher <boucher.tra...@gmail.com> 2009-11-19
17:09:37 PST ---
Created an attachment (id=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
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
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
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------