www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3527] New: DMD won't compile on FreeBSD (freebsd.mak doesn't seem to be maintained)

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3527

           Summary: DMD won't compile on FreeBSD (freebsd.mak doesn't seem
                    to be maintained)
           Product: D
           Version: unspecified
          Platform: x86
        OS/Version: FreeBSD
            Status: NEW
          Severity: trivial
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: boucher.travis gmail.com


--- Comment #0 from Travis Boucher <boucher.travis 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
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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 19 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3527



--- Comment #1 from Travis Boucher <boucher.travis gmail.com> 2009-11-19
17:11:38 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 19 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3527


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |FIXED


--- Comment #2 from Walter Bright <bugzilla digitalmars.com> 2009-12-07
01:30:03 PST ---
Fixed dmd 1.054

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 07 2009