httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: "free" borland C++ compiler
Date Fri, 23 Jun 2000 18:11:35 GMT
> From: TOKILEY@aol.com [mailto:TOKILEY@aol.com]
> Sent: Friday, June 23, 2000 4:46 AM
> 
> and I will re-post tomorrow and answer all you questions

not a problem...  If I took 8 hours generating all the q.s
I don't expect them answered in 1 :)

> 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?

No, if all agree on how the makefile faciliates rolling the
release, we could make a parallel file.bor.mak, and even fixup
for it... let's get it building before we worry that detail :)

> 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.

Nuf said, we can address it.  Actually, just change the temp
file name line up top, and undo the 'unlink and rename' bit
at the end, for the time being.

> 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. 

No, they do not, although several 'compatibility scripts' are
in preparation.  For a free tool, I not too concerned, but for
big releases, sure we can have parallel.  But Don't Expect
dozens more make structures (borland mak, builder ide, whatcom,
etc, etc) to sit out there.  This make life easy for all, and
the .pl can be changed but just about any hacker who doesn't
'like that flag.'

Picture .pl's rolled at release for the windows .zip and 
installer release only.

> 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.

That's the direction it's headed, yes, but I believe the .pl can
be compiled in activestate perl anyways.  I like the perl script
(with extra docs) simply because it lets you or Ozgar or I to
fiddle flags till we get bored with it :)
 
> 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.

Well on stage one I'm happy to enquire of them.  But Borland won't be
supported for at least one release cycle until users consistently
report success.

> >  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.

Based on that I will jump on adding the new rule as soon as two other
issues are sorted out.

> >  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. 

I'm refering to a ILINK32.CFG file to that binary, and it's -only-
documented in help and readme, (searched their entire site) so I'm 
nearly certain it's a 'should have been', and not a real feature.
Has nothing to do with make.exe.

> 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. 

MS nmake has the same problem, which is why you see child invocations
of nmake instead of SHORT= and LONG= in the debug/build tests.

> >  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.

Fair enough.  But since all our stuff is explicit, and hopefully complete
already, we just need to watch the symbols from the vc lib and c0.obj.

> >  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.

But we don't.  That's where the def file sets things up correctly, and the
borland make seems to be doing fine so far.
 
> 'You have to (add/subtract) the underscore or it won't work'.

Rest assured we will not :)

Bill

Mime
View raw message