[CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program

[Chris Rees]

On 25 October 2012 22:32, Garrett Cooper <yanegomi at gmail.com> wrote:
> On Thu, Oct 25, 2012 at 2:23 PM, Marcel Moolenaar <marcel at xcllnt.net> wrote:
>
> ...
>
>> I think there are 2 reasons why not to:
>>
>> 1.  The people working on ATF have not raised this concern and
>>     have expressed that using the WITH_BMAKE knob is but a small
>>     price to pay. So let's work the bmake side and be able to
>>     get rid of the knob as soon as possible.
>
> It is annoying with the magnitude of build-related errors, but I have
> a workaround.
>
>> 2.  More knobs isn't better -- we must have none of the knobs in
>>     the end, so the more we create, the more work we have to get
>>     rid of them. That's just more work spent not focusing on the
>>     task at hand and thus more time wasted.
>
> Yes, but not being able to update one's machine makes me sad panda.
>
>> In short: this isn't a 2-knob problem by any stretch of the
>> imagination.
>
> The real issue is that I need to take the patch Simon developed, run
> with it, and in parallel he needs to -- and hopefully already is --
> engage portmgr to get it through a number of exp- runs to make sure
> bmake does what it's supposed to do with his patch. Backwards
> compatibility will need to be maintained for ports because ports has
> to work on multiple versions of FreeBSD [where bmake isn't yet
> available/present], so maybe a fork in the road for bsd.port.mk should
> be devised in order to make everything work.

Now you've terrified me, and probably most other ports people too.

Is there a Wiki page where the actual benefits of moving to bmake are
made clear?  This is a major, *major* upheaval, and having two
versions of bsd.port.mk for years is simply not an option.

Have you discussed this on ports@?

Chris