httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: Massive changes to Win32 generated MAK files
Date Sat, 08 Apr 2000 01:54:24 GMT

In a message dated 00-04-07 10:06:56 EDT, William A. Rowe, Jr. writes...

> > From: TOKILEY@aol.com [mailto:TOKILEY@aol.com]
>  > Sent: Friday, April 07, 2000 1:38 AM
>  > 
>  > Given the size and the complexity of your codebase 
>  > I think you can pretty much assume the following of any Win32
>  > programmer that will be seriously trying to compile Apache...
>  > 
>  > 2. Even if a developer WANTS to compile with Borland they will 
>  > NOT be trying to do so with the 'free' version and they will already 
>  > have the BC IDE and the VPTOBPR.EXE utility to perform the 
>  > necessary project file conversion(s).
>  
>  I believe we are thinking in terms of admins.  Yes, I would now
>  state that every 'serious' Win32 developer works within an IDE.

Actually... I am not sure I agree with you there. The point I was 
making is that I am pretty certain that every serious Win32 
developer HAS a copy of MSVC but that doesn't meant the 
assimilation is complete and that they actually USE it.

Example: In my shop... we can COMPILE with MSVC but no one
actually USES the MSVC GUI. I still think the GUI sucks ( especially the
code editor itself ) but I have long since realized the need to 
HAVE the MSVC compiler/linker. Micsrosoft has now gone 
crazy with the SDK releases and you just can't do anything
serious in Win32 anymore unless you START with their SDK code
and their compiler. For development you will still find me ( and many 
others ) at the command line.

>  But I'm not really sure that's our audience for the Borland
>  compiler.  You are right when you mention Borland 'fell behind'
>  in usefullness (I havn't used their products since '91, and their
>  bundled resource editor back in '93, which was at one time vastly
>  surperior to MS's.)  

I heard that. The Whitewater stuff was great. Not sure what 
happened to them. I think the Borg cube got them early on.
It's a shame that their 'fall-behind' in the tools area has masked
the fact that it is STILL a better compiler than MSVC. 

All that matters is the .ASM output and if you look at Borland
and MS output side by side there is no question who has acutually
read the Intel manuals, even today.
  
>  The idea is who's product.  I believe a mak technology (not being
>  specific here :~) is really more useful to throw switches that
>  might interest the admin.  Batch files don't do that impressive
>  a job of compiling.

I would be the last person to suggest that using a .BAT 'rawmake'
script is in any way 'superior' to an actual makefile... but my point
was that to me... it just doesn't matter. When I go to sew code 
back together it just doesn't matter to me if it's 'pretty' or not...
only if it WORKS, and I think too much focus on creating 
some sort of 'elegant' build procedure is always just wheel-spinning.
  
>  BTW - my point is that MAKE -is- included in their free product.
>  The Q remains, how do we want to take advantage of that.  If we
>  are that scared of the VPTOBPR results (and won't adapt our dsp's
>  to be sufficiently generic), then the MAK result is decided.

Yes. Every MSVC .DSW converter I know of ( Including the one
I wrote myself ) depends in some way on you being 'aware' of the
specific limitations of the converter while you are fooling with and
changing the MSVC 'project' itself. Every converter has it's 'gotchas' 
and though easily accounted for... if you are not EVER willing to alter 
the design of your MSVC project itself to facilitate conversion then you
are sunk.

What I think you should do is simply not look at it as an 
'all or nothing' thing. Just 'Export' whatever (Win32) .MAK file you have
that WORKS and follow your own very well established 'You are on your own'
policy. It's just not worth any CPU cycles or coding effort until the
new version stops changing so much.

>  But... we may have an option.  If we postpone MAK files until the
>  release of 2.0, and only roll them with the full release, we will
>  keep admins happy who want to build.  You are right, alpha developers
>  can work from the dsp files as well as anything.
>  
>  Bill

Exactly. I don't know why you are even considering anything else
AT THIS TIME.

If you want to pursue the 'let's compile with Borland' thread then
the makefile ( or lack therof ) is going to be the least of your 
worries. The real hurdle you have to face is not that the MSVC
.MAK won't work with the BC compiler... it's the fact that your
own Win32 code has been SPECIFICALLY written for the 
MSVC compiler itself. Whoever coded a lot of the Win32 stuff
had obviously never worked with any Borland compiler or they
wouldn't have 'married' the code to MSVC in the first place.

Anyone who has worked a lot with both knows the 'tricks' you
have to do to end up with 'C' code that works with BOTH 
compilers and not just one ( It goes far beyond simple ANSI and
has more to do with people who shall remain unnamed simply
deciding to make the 2 compilers incompatible. )

I was the one who suggested using the Borland compiler for
Apache over 2 years ago and Brian Behlendorf and I tried
to hash it out way back when but it fell off the table. 

I was seeing a 2 or 3 fold speed increase in Apache over
2 years ago simply by running it through Borland instead
of MSVC. The Borland STDLIB stuff is TIGHT. MSVC has 
actually improved since then but I think Borland still 
produces faster/tighter code even if it is now in the 'geek'
arena with regards to testing/noticing the difference.

When I sent Brian Behlendorf the 'How to re-write Apache so
it compiles with Borland' document which showed all the
changes that would have to be made to get away from the
MSVC specific 'C' code the response was 'We are not willing
to make so many changes at this time' or something like that.

The 'killing field' is the MSVC specific 'C' code in your
codebase... not the makefile issues. That's a cakewalk.

Yours...
Kevin Kiley
CTO, Remote Communications, Inc.
http://www.RemoteCommunications.com

Mime
View raw message