[prev in list] [next in list] [prev in thread] [next in thread] 

List:       macports-dev
Subject:    Re: [GSoC] Progress Report
From:       Mojca Miklavec <mojca () macports ! org>
Date:       2017-06-06 15:11:55
Message-ID: CALBOmsaPiiXofjQoFxjhHD3PeyoFOf4PvRta-aq9h95T12mNqA () mail ! gmail ! com
[Download RAW message or body]

On 6 June 2017 at 04:15, Zero King wrote:
> On Mon, Jun 05, 2017 at 02:08:20PM +0200, Rainer M=C3=BCller wrote:
>>
>> How is getopt relevant for the timing? If the dependency on getopt is a
>> problem, let's find a portable solution for mpbb. Duplicating the exact
>> same functionality we already have does not make sense to me.
>
> getopt has to be installed in a different prefix to avoid conflicts with
> tested ports. It's not ideal to install another MacPorts on Travis VMs
> because it would be lost in the next build.

Don't worry about premature optimisations too much.

As Rainer said, we could avoid using getopt, rewrite the mpbb scirpts
to perl / python or whatever else.

But even if you have to install some minor dependencies to the same
prefix, I would not worry about that at this point, in particular
because you don't need to do a cleanup at the end anyway. It's clearly
suboptimal, but I believe this is something that can get fixed later.
I don't know if you need any other tools which are not provided by the
machines they use.

That said, the biggest power of mpbb are probably the tcl functions,
something that's much more difficult to rewrite to a different
programming language. But many of them could probably be integrated to
MacPorts core. Like: listing all subports from a given list of ports,
installing dependencies of a particular port without installing the
port itself etc.

But then again, if using mpbb is more limiting you than helping you,
... then well ... use whatever works best.

Mojca
[prev in list] [next in list] [prev in thread] [next in thread]