Hi Yang,
Am 12.01.2011 03:42, schrieb Yang Tse:
> 2011/1/5 Guenter wrote:
>
>> @Yang: hope you read that here, and can take a look at the macros in
>> curlrules.h and probably have an idea what we can do here ...
>
> I've just updated curlrules.h and Borland's makefiles...
thanks for taking a closer look at it ...

> First of all, the only version of BCC I've tried is the 5.5.1 free
> one. AFAIK all of Borland's BCC are 'one-pass' compilers with an
> integrated internal preprocessor. And fortunately with an additional
> external preprocessor which is capable of accepting same options as
> the compiler.
>
> Both, the internal and external preprocessors are capable of using the
> token-pasting operator ##, and both are capable of doing macro
> expansion properly in many situations.
>
> BUT as soon as both features are required to properly define a macro,
> forget about ISO preprocessor compliance :-( and forget about 'proper'
> macro expansion. No matter the levels of indirection used the results
> are always ISO-surprising, at least for libcurl's intended usage.
yeah ....
at this stage I was too, and gave up after some hours of testing with
the external preprocessor. Funny thing is that if you define
CURL_SUFFIX_CURL_OFF_T in curlrules.h to L then all is fine - it only
dislikes i64 !!

> The modification done to curlrules.h is BCC 5.5.1 specific and
> requires usage of the external cpp32 preprocessor, makefiles updated
> accordingly. Every source file gets externally preprocessed first with
> cpp32 generating an intermediate source code file, I used extension
> '.int' for these, and later compiled with bcc32 to generate each
> object file.
>
> We can not further expand support in curlrules.h to other BCC versions
> unless someone shows up with a version different than 5.5.1. I would
> assume that older versions exhibit same problems and that the same
> definition in curlrules.h would be valid. But, who knows!
well, most likely everyone uses this free version 5.5.1 - if someone
uses another commercial version then he must speak up here and provide
details.

Now some comments on your recent commits:
commit 61623b74e3337c9be44a7865eeb558f64c00576f
I dont believe that the check for BCC-make makes much sense since I know
only 2 other make tools which may understand the syntax up to the point
that the error message is really printed out, that is Watcom wmake and
M$ nmake, and since both are differently named its unlikely that someone
uses these when he wants to compile with BCC; I guess you want to
separate from GNU make which is named same, but unfortunately this
doesnt work (line number wrong since output below is from testmake):
Makefile:2: *** missing separator. Stop.
therefore I think we can remove this check again.

commit 5f7d34811a1ff21d4a8962e3c7c99d4a702bd684
I think we should use here '!ifndef BCCDIR' so that all envvar tests
look the same; the helpfile states that this syntax is equal to '!if
!$d(BCCDIR)', and a test for a defined but empty BCCDIR var seems a bit
strange since AFAIK its hard to even produce an empty env var in Win32
world.

commit 42f5e8a0f1729b17547acfc6625e58e583811e8d
its unclear to me why you changed the CP / RM macros and did then append
the NUL redirection to the commandline - what was wrong with my macro
define? It works fine for me on XP and W2K3, and avoids to append the
redirection to each single commandline + makes it possible to just
change the macro only in case you need (for debugging purpose or whatever).
Then why did you change all paths to use backslash instead of
forwardslash? I admit that I had probs when I tried to use ilink32, but
at least the makefile version before your commit worked fine with
forwardslash.
The macros for mkdir and rmdir let BCC-make execute my GNU binary
pedants instead of the internal CMD commands, I think we should use the
md / rd abbreviations here.

Please take this as comment and not as rant :-)

Greets, Gün.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-01-13