httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: 2.0.23 tarballs up
Date Fri, 10 Aug 2001 20:40:38 GMT

In a message dated 01-08-10 20:14:25 EDT, Cliff Wooley writes...

> On Fri, 10 Aug 2001 wrote:
>  > Except for the LF only in all the .DSW and .DSP Win32 project files
>  > you DO have a working Win32 2.0.23 tarball.
>  >
>  > Thanks to Jerry Baker's help here is the (final?) story on that...
>  >
>  > 1. As long as you use any version of WinZip ( versus PKZIPW for Win32 )
>  > and that version of WinZip has a feature under Options|Miscellaneous
>  > that says 'Auto-convert LF to CR/LF on .TAR unpacks' and that option
>  > is ON ( Usually the default ) then all is OK. The .tar.gz on the dev site
>  > will unpack, load into MSVC, and compile straight away.
>  >
>  > 2. The only people it isn't going to work for are those not using WinZip
>  > and don't have the auto-convert LF option. ( Like me ).
>  Cool.  That's a nice feature.  I doubt we want to rely on it, of course...
>  so we need a good CRLF'd tarball.  I haven't looked at Jerry's yet, but I
>  hope to do so this evening sometime.  [Disclaimer: I might not have
>  time... I'm getting ready to leave for SIGGRAPH tomorrow afternoon.  I'll
>  do my best.  If all else fails, I'll have plenty of connectivity at the
>  conference, so I can take care of it from there if need be.]

I suppose I should have mentioned....

All Jerry did was re-pack his un-pack of the 2.0.23 dev site tarball
after he used WinZip to create a working dir. Jerry said he used
TAR ( for Win32 ) to re-pack the whole deal.

However... as of this writing... you will still seem to have the same
problem(s) if you use PKZIPW versus WinZip to unpack Jerry's
new tarball ( At least I do using PKZIPW ). My guess is that there 
is, in turn, something weird about TAR for Win32 that starts taking 
all the CR/LF back off again or something? Who knows.

Best bet: Send PKZIPW for Win32 to the Smithsonian and just
install/use WinZip 7.0 or better.

If you use WinZip then EITHER the dev tarball or Jerry's re-pack
will load and compile straight away.

>  > I think once the original Win32 project files are stored 'as-is' into
>  > the tarball ( as binary versus text to preserve CR/LF ) then this is
>  > all a moot point and both PKZIPW and WinZip will produce a
>  > loadable Apache.dsw project. That's the way it's always been
>  > but I might be the only one left using PKZIPW for Win32 so
>  > it probably doesn't matter.
>  Give or take the need for carriage returns, they really are text files and
>  should be treated as such.  

Actually... they are not JUST text files.

There are huge disclaimers in these Microsoft files that say 
'DO NOT EDIT' and if you make certain simple cosmetic 
changes to them you will get one of 2 results...

1. The .DSW file will never load again into the MSVC GUI.
2. MSVC will half-load it and then say 'This file was not
generated by MSVC'.

The real poop about these files is that first few lines of text
MUST be a certain way and so must the relative position 
of TAG/SECTION fields after that. 

Example 1: If you add 1 blank line to the top of the file then MSVC
will never load the file again. Kinda like the SHEBANG line in
a shell script. Move the SHEBANG down a few lines and all
hell breaks loose. 

If you change the 'relative' number of blank lines between certain
sections then that's when MSVC bitches about 'This is not an
MSVC generated file'. Actual rules remain a mystery and 
Microsoft isn't saying. They don't want anyone to easily write
APPS that can create their own MSVC project file(s).

It also has to do with the (ongoing) GUI IDE war(s) with 
Borland and others. You would think that you should be
able to create project files for either compiler that could
be used for either compiler but you would be wrong. That
doesn't sell compilers.

So yea... they are TEXT files... but it really would be better to
check them in as binary straight from a working Windows box
to be really sure nothing 'changes'.

> Having the change history is very useful.
> When changes to the .dsp's get checked in, people (including myself)
> actually DO look at the commit mails to see what the diffs are... if the
> files were -kb in the repository, this wouldn't really be possible.

You mean just because something checks in as 'binary' you can't
do a 'diff' on it? That sucks. I didn't think 'diff' cared. Isn't it smart
enough to take EITHER LF or CR/LF as 'EOL'?

>  > So that's 3 +1's for 2.0.23 windows version compiling and running OK
>  > ( Myself, Jerry and Sebastian ).
>  >
>  > No fancy tests done here yet but it certainly serves up pages
>  > and stays alive OK.
>  Great!  Glad to hear it.
>  Thanks,
>  Cliff

View raw message