portupgrade bug: -M no longer works after v2.1.0

[Jonathan Noack]

Atanas wrote:
> Matthias Andree said the following on 7/11/06 1:48 PM:
>> Atanas <atanas at asd.aplus.net> writes:
>>
>>> Recent portupgrade versions no longer obey the -M command line switch,
>>> i.e. any optional arguments to be prepended to each make command.
>>>
>>> How to reproduce:
>>>
>>> # portinstall -M "APACHE_HARD_SERVER_LIMIT=1024" www/apache13
>>> ...
>>> ===> src/ap
>>> cc -c  -I../os/unix -I../include -I/usr/local/include  -funsigned-char
>>> -O2 -fno-strict-aliasing -pipe
>>> -DDOCUMENT_LOCATION=\"/usr/local/www/data\"
>>> -DDEFAULT_PATH=\"/bin:/usr/bin:/usr/local/bin\" -DHARD_SERVER_LIMIT=512
>>> `../apaci` ap_cpystrn.c
>>> ...
>>>
>>> Note the -DHARD_SERVER_LIMIT=512 above.
>>
>> Does it work if you type (you can omit the env in /bin/sh, bash, (pd)ksh
>> and other Bourne-like shells):
>>
>> env APACHE_HARD_SERVER_LIMIT=1024 portinstall www/apache13
>>
> Of course it would, but this just bypasses the problem. There are other 
> ways to work this around as well - like not using portupgrade at all and 
> building everything with make.
> 
> The problem is that there's a bug introduced by some of the recent 
> portupgrade versions that changes its documented behavior. The '-M' 
> switch in partucular no longer works, thus causing any existing 
> port/package installation scripts depending on that switch to build 
> packages with incorrect optional parameters.
> 
> It's not a problem with a particular port. The www/apache13 port was 
> given just as example how to reproduce the bug.
> 
> This affects _all_ ports when installed/upgraded/built via portupgrade 
> and when the '-M' switch is used.

Try '-m' as a workaround.

-Jonathan