From: Richard Levitte <rich...@levitte.org>
> sms> When _all_ the product files get put into architecture-specific
> sms> directories, then cleaning gets easy.
>
> Agreed, but except for cleaning purposes, is there a reason to put
> architecture-independent files in architecture-specific directories?
No, but it would be good to segregate all the generated files from
the source tree. For example, copying C source files into [.APPS] and
[.TEST] seems to be an unnecessary waste of time and disk space, with no
obvious benefit.
> sms> I haven't done anything with the new (1.0.0 beta X) stuff
> sms> because it wasn't not clear that anyone was looking at the
> sms> changes I made to the old stuff. It's still not clear.
>
> I've looked, as I've said before. I've also applied the functional
> bits. Not the cosmetic bits, not the non-copying bits, as they really
> should make no difference, or?
The file copying stuff makes no sense to me. Eliminating it also
makes it easier to compare a VMS source tree with a UNIX source tree.
Why do it? A bad idea does not get better just because it gets older.
Here's one annoying cosmetic thing. In install.com:
$ IF (F$GETSYI("CPU").LT.128)
$ THEN
$ ARCH := VAX
$ ELSE
$ ARCH = F$EDIT( F$GETSYI( "ARCH_NAME"), "UPCASE")
$ IF (ARCH .EQS. "") THEN ARCH = "UNK"
$ ENDIF
Ignoring the annoying tab indentation, why mix styles like
ARCH := VAX
and
ARCH = "UNK"
???
I prefer to use "=" with a quoted string instead of ":=" with an
unquoted string, because it avoids any unplanned case changes, but why
mix them this way?
And that tab indentation is pretty annoying, and it's not used
everywhere. See, for example, makevms.com. Where, by the way, that
seven-line architecture determination is fluffed up to about 3X that
size. Using the same code fragment to do the same job everywhere is not
merely a cosmetic change. I claim that it improves maintainability. If
I had my way, I'd have a single procedure to do that particular job, and
everyone would use it. But I suppose that that would be just one more
cosmetic change, so I didn't try to push that one through.
> Also, the SSLfoo to SSL_foo logical name conversion... hmm, did I
> apply that? If I did, it should be reverted, at least in the 0.9.8
> series, as such a change will only confuse the users...
I didn't change any logical names, only the names of the actual
library files. Yes, without some documentation, it might confuse some
users. I don't see why SET FILE /ENTER couldn't be used to aid a
transition to what I claim would be _less_ confusing names. 1.0.0
sounds to me like a near-ideal time to make the switch.
> I haven't had a VAX account for a long time... someone give me one
> and I'll play...
I'd spend some time looking for a user who would care about VAX C
before I spent any time trying to use it to compile any modern code.
DEC C has been around since about when, mid-1994? On my fastest VAX
(4000 model 200), building this stuff takes a whole day. I don't keep a
VAX running continuously, so playing with mine would not be convenient
(especially in summer).
------------------------------------------------------------------------
Steven M. Schweda s...@antinode-info
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
