httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: "free" borland C++ compiler
Date Fri, 23 Jun 2000 05:45:45 GMT

Bill (Wrowe)...
Kevin Kiley here...

I have every intention of helping all I can with allowing the
'official' release of Apache to support the Borland compiler
and I will re-post tomorrow and answer all you questions
with much more detail but it's very late here and I have
been programming all day so this has to be just a quick-back.

In a message dated 00-06-22 23:27:18 EDT, William Rowe writes...

>  Attached is the current 'iteration' of the perl script.

It looks good... but quiz me...

I had to actually re-install Perl on my machine just to run
your script and the thought occurred to me... will people
who want to use the 'free' Borland compiler actually have
to suffer through the humongous Perl download just to
be able to convert the makefiles or is the script just for
ASF purposes to auto-generate a separate set of Borland
.mak files that will go out with the distribution?

The fact that you are making no attempt to change the
names of the converted makefiles seems to suggest that
you picture people downloading the Apache source code
and, if they want, just running your script and converting
everything to Borland.

Forget the fact that this is really going to mess people
up who are trying to use BOTH compilers and who
accidentally 'export' an MSVC .mak again after having
converted to Borland... it just seems like trying to use
the same set of names for 2 compilers is going to 
generate more PR reports than you might imagine.

I haven't had to go throught the 'normal' Apache install for
so long now I am completely clueless as to whether you
HAVE to have Perl installed to ever run the installation
and/or build. If you don't... it seems weird to require it
for such a simple parsing job.

The reason I ask is that I already have the 'C' version of
your script here and if you see this as a better option
rather than requiring people who don't have Perl to 
suffer the download then I will sent that 'C' version and
it can become an exectuable 'tool' that comes with Apache.

>  I realize you and Ozgar are both dedicated Borland afficiandos,

Ozgar maybe... but to me it's just another compiler. You should
know up-front that while I have done many things with Borland
over the years and I find their assembly language output superior
to any other PC based 'C' compiler... I do not consider myself
a 'Borland afficianado'. That implies product endorsement and
believe me... I can rip the Borland products a new one for the
things they DON'T do just as fast as I can slice up MSVC.

If the ASF is seriously going to support the Borland products
then I suggest some attempt be made to notify Borland of this
fact and solicit the best help possible. It is only in their interest
to help and I can't imagine why they would not.

I'm not kicking my own knowldege of the products and I am thrilled
that Apache is finally going to support something OTHER than
MSVC... but I just think an actual relationship with Borland
and/or the help of someone who actually works there would
be the best thing for Apache in this regard.

>  but we need to maximize compatibility, not exploit features for
>  the public release.  (Yes, I realize we have done so with MSVC,
>  and no more 'on purpose' than either of you propose.)

Rest assured... I have seen your patches now and the way 
you WANT to do it and I don't see any show stoppers.
  
>  The def for the IMPORTS tag will definately be verboten.  May
>  I ask, does ilink32 have not -one- blinking option to create
>  the implib???  Forget the IMPORTS nonesense, since that makes
>  modules a nightmare.  So let me know if we have to invoke implib
>  on the libraries we create in a second operation.  (I -really-
>  hoped to avoid that!)

If you are unwilling to play with the .DEF files then it
looks like you might be stuck with the second .EXE ( implib ).
More on this tomorrow.
  
>  Feel free to comment on the flag options!  

Roger that. I have seen the ones you are trying to use
and I have some suggestions for others.

> I think your notes misspoke about CW32MTI 
> (the name implies to me this is the import 
>  lib for the dynamic library, but I could be wrong.)  

CW32MTI is what you are supposed to use if you are
using the ILINK32.EXE incremental linker for a multi-threaded
Win32 binary. CW32MT is the one you are supposed to
use for a reqular non-incremental build with TLINK32.EXE

Has nothing to do with IMPORT stuff, AFAIK.

> Pull down tonight's tree and whack it with msvcmaktobcc.pl.  
> And yes, it won't build past the .dll - since there is no 
> ApacheCore lib to link with (and as I said, we need to fix it right.)

If I get a chance tomorrow I will do so.
  
>  Also, the free bcc5.5 product states you may list options in the
>  ilink32.cfg file in the borland binaries folder.  Hogwash, or
>  so it appears.  It also appears you cannot actually use a LIB env.
>  variable, either.  I did manage to configure the bcc32.cfg file
>  for the bcc32 paths, but have no friggin clue how to get the linker
>  paths set up.  

Borland didn't write the MAKE.EXE that they use and it has
historically caused problems that should bear no reflection on
the mainline compiler and linkers. Their MAKE.EXE has always
been a little brain dead when it comes to environment variables
and 'finding' the config files. The inability to access some
environemnt variables is related to the other issue you have 
already conquered regarding the 'SOURCE=' thing. The reason
it won't work with MAKE.EXE is because it has trouble 'remembering'
what that environment variable is supposed to be if it keeps changing
during the MAKE. Also... Borland MAKE.EXE works from the 
'bottom up' and not 'top down' as NMAKE does and that causes
problems as well.

>  Some asides, I'm avoiding pulling in that 1MB monstrosity 
>  IMPORT32.lib, and did path the psdk folder they provide.  The extra
>  kernel32.lib in some cases is a result that their implib's don't
>  resolve their own imports for the c libs, and chaos ensues.  That's
>  how I found my way to the MTI libs, since they only really 'link'
>  directly to kernal, rather than the whole gobs.

Hmm... have to check my notes but if I recall I settled with IMPORT32
itself for the OPPOSITE reason(s)... I got tired of all the BLOAT in
my code from doing it other ways.
  
>  One last thought; If done right, no one knows the difference if they 
>  are loaded by a borland or ms compiled ApacheCore.dll - and module 
>  writers will cheer :)

In that case then... you have to conquer the 'underscore' game.
Microsoft adds underscores to just about everything... Borland
does not unless you 'tell' it to.

Witness MSVC _findfirst, _findnext versus Borland findfirst, findnext.

You don't want to get caught in that trap and be responding to
thousands of module writer PR reports which all have the same
answer...

'You have to (add/subtract) the underscore or it won't work'.

>  Bill

Mime
View raw message