Re: [ft] Compiling freetype 2.3.9 with bcc fails

[mpsuzuki]

Dear Mirco,

Could you try attached patch? Please revert my previous
patch (adding CCexe_CFLAGS etc) before applying this.
The patch changes APINAMES_EXE target more flexible and
"-e" is used to generate objs\apinames.exe.
I could build freetype.lib from GIT HEAD source + patch.

diff --git a/builds/compiler/bcc-dev.mk b/builds/compiler/bcc-dev.mk
index ba1a88a..b9229b4 100644
--- a/builds/compiler/bcc-dev.mk
+++ b/builds/compiler/bcc-dev.mk
@@ -52,7 +52,8 @@ L :=
 
 # Target flag -- no trailing space.
 #
-T := -o
+T  := -o
+TE := -e 
 
 
 # C flags
diff --git a/builds/compiler/bcc.mk b/builds/compiler/bcc.mk
index 509cb72..ff385ed 100644
--- a/builds/compiler/bcc.mk
+++ b/builds/compiler/bcc.mk
@@ -52,7 +52,8 @@ L :=
 
 # Target flag -- no trailing space.
 #
-T := -o
+T  := -o
+TE := -e
 
 
 # C flags
diff --git a/builds/exports.mk b/builds/exports.mk
index 5452b35..52f2912 100644
--- a/builds/exports.mk
+++ b/builds/exports.mk
@@ -47,8 +47,8 @@ ifneq ($(EXPORTS_LIST),)
   #
   # Note that $(APINAMES_OPTIONS) is empty, except for Windows compilers.
   #
-  APINAMES_SRC := $(TOP_DIR)/src/tools/apinames.c
-  APINAMES_EXE := $(OBJ_DIR)/apinames$(E_BUILD)
+  APINAMES_SRC := $(subst /,$(SEP),$(TOP_DIR)/src/tools/apinames.c)
+  APINAMES_EXE := $(subst /,$(SEP),$(OBJ_DIR)/apinames$(E_BUILD))
 
   $(APINAMES_EXE): $(APINAMES_SRC)
          $(CCexe) $(TE)$@ $<
diff --git a/builds/win32/win32-def.mk b/builds/win32/win32-def.mk
index a82b146..e6ae31c 100644
--- a/builds/win32/win32-def.mk
+++ b/builds/win32/win32-def.mk
@@ -22,6 +22,7 @@ PLATFORM  := win32
 # The executable file extension (for tools). NOTE: WE INCLUDE THE DOT HERE !!
 #
 E := .exe
+E_BUILD := .exe
 
 
 # The directory where all library files are placed.




On Tue, 14 Jul 2009 16:08:24 +0900
address@hidden wrote:

>Hi,
>
>Thank you for the experiment, yes "-o" was the root of
>our bcc32 problem. I reached same conclusion. My misunderstanding
>about 1-step & 2-step was solved. I didn't receive the
>error you got (about HELLO.OBJ), but I agree with your
>observation that "-o" causes problem.
>
>Also thank you for the proposal to use "-n" option to
>specify the directory of the executable. But now I'm
>trying to use "-e" option to specify the pathname of
>the executable. If you have sparetime, please check
>"-e" accepts the pathname including directory, aslike
>
>       bcc32 -eobjs\apinames.exe src\tools\apinames.c
>
>In my environment, it finishes successfully, and
>apinames.exe does not crash.
>
>The reason why I try "-e" instead of "-n" is that the
>default output filename is dependent with the compilers.
>Most Unix compilers generates "a.out" from "hello.c",
>but bcc32 generates "hello.exe" from "hello.c" by default.
>So if I use "-n" and leave the output filename for
>compilers' default, we don't know the output filename.
>
>Regards,
>mpsuzuki
>
>On Tue, 14 Jul 2009 08:40:54 +0200
>Mirco Babin <address@hidden> wrote:
>
>>Hi,
>>
>>Compiling test.c fails:
>>bcc32 -ohello.exe hello.c
>>CodeGear C++ 5.93 for Win32 Copyright (c) 1993, 2007 CodeGear
>>hello.c:
>>Turbo Incremental Link 5.81 Copyright (c) 1997-2008 CodeGear
>>Fatal: Unable to open file 'HELLO.OBJ'
>>
>>This works:
>>bcc32 hello.c
>>CodeGear C++ 5.93 for Win32 Copyright (c) 1993, 2007 CodeGear
>>hello.c:
>>Turbo Incremental Link 5.81 Copyright (c) 1997-2008 CodeGear
>>
>>Hello.exe is created and works fine.
>>
>>
>>
>>I think your conclusion about the -o switch (it may not be used for an
>>executable name) is correct.
>>I found out that bcc32 -n./objs hello.c outputs the .obj and .exe file to
>>the ./objs subdirectory
>>
>>My conclusion about the current directory is wrong. It is the -o flag that
>>may not be used.
>>
>>Regards,
>>Mirco
>>
>
>
>_______________________________________________
>Freetype mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/freetype