Richard Salz wrote:
>> E.g., the patterns for linux are fine, but in order to avoid confusing
>> the environment, I'd like to override cc with gcc -m32 or gcc33 and
>> otherwise accept openssl's other opt patterns verbatim.

> something like this, around line 943:
> my $cc = $ENV{'CC'} || $fields[$idx_cc];
> So you can do
> CC=gcc33 ./Configure
> or ( setenv CC gcc33 ; ./Configure )

Wouldn't care to have that much code times 20+ options that are plugged
in from the pattern string, and if you are overriding, you probably do
not want to pick up the CC envvar, because the rest of the flags are
very closely tied to the compiler type. Not a real solution, and back
to patching openssl, which I'd like to quit.

This is the syntax I'm thinking of...

../Configure platform:cc:cflags:unistd:thread_cflag:sys_id:lfla gs

today sets the remaining 17 flags to defaults - not to {platform}'s original
defaults, but far less useful defaults. For an illustration, compare
configuring with your {platform}:gcc to simply {platform}.

I'm not suggesting we break this syntax; we really shouldn't.

So the alternate syntax I'm thinking of is...


which would preserve all but the three fields assigned by default
to the given platform.

The rule is that the first option, the cc choice, must have a leading
= or + to trigger the behavior. A field of :=value: would replace the
existing table field, a field of :=: would unset the table field, and
a other :value: entries would append to the existing table field (space

In the first field :+-m32: would append -m32 and trigger this behavior,
:=gcc33: would set gcc32 and trigger the behavior, while :+: alone is
a shorthand to simply trigger the new behavior but leave the existing
cc value alone. The :+ meaning applies only to the first field.

I specifically choose not to give :+xxx: a different meaning in the
remaining fields because + is very often a legitimate leading character,
while there's not a single example where = is a legitimate leading character.

I considered a corresponding remove partial syntax but that seems just a
bit to aggravating, and can usually be accomplished by simply overriding
the default with :=value: syntax.

Feedback on this proposal?

__________________________________________________ ____________________
OpenSSL Project
Development Mailing List
Automated List Manager