redports.org - The public FreeBSD ports development infrastructure

[Bernhard Froehlich]

On 04.01.2012 19:21, Greg Larkin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 1/4/12 3:07 AM, Bernhard Froehlich wrote:
>> On 03.01.2012 22:32, Greg Larkin wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 12/29/11 6:44 AM, Bernhard Froehlich wrote:
>>>> Hi Porters!
>>>>
>>>> I am happy to announce that redports.org has finally
>>>> reached the point where I think It's safe to be used
>>>> by everybody! In case you never heard of it before
>>>> redports is the result of an idea born at EuroBSDCon
>>>> 2011 in Karlsruhe to give Port Maintainers and Port
>>>> Committers a public service to test their new ports
>>>> or ports patches during development or before
>>>> submitting a ports PR.
>>>>
>>> [...]
>>>
>>> Wow!  Stellar job, Bernhard, and I'm looking forward to using
>>> redports.org for fixing ports that are broken under clang.
>>
>> Hope you don't want to do that today because during the night the
>> current building machine paniced and needs someone power cycling
>> it. I will do this in the evening so no builds today :(
>>
>> It looks like I could get some hardware from portmgr so
>> hopefully more hardware and redundancy is available soon.
>>
>>> I noticed one minor typo on https://redports.org/buildgroups:
>>> automaticaly -> automatically
>>
>> Thanks, it's fixed now!
>>
>
> Hi again Bernhard,
>
> It looks like ports are building fine now.  As I was building the 
> first
> port on your system, I thought of an enhancement, and I am interested 
> to
> know how difficult it would be to implement.
>
> I maintain various p5- and py- ports, and I often want to test them
> under multiple versions of Perl and Python, in case there are
> conditional behaviors in the Makefile.
>
> Assuming you're not planning on allowing users to create their own
> builds, what about adding the ability to set build variables in a
> make.conf file?  For instance, if I commit etc/make.conf to my 
> personal
> repository location, redports would overlay my options before 
> starting
> the build.  Then I could do things like force Python version 2.7, 
> Perl
> version 5.10, etc.
>
> What do you think?

That sounds a lot like OPTIONS support. Tinderbox is already able to do
that so the only thing I need to solve are that it has to work in a 
shared
environment. That means it will have to build all dependencies from 
scratch
all the time because there are too many combinations and we don't 
really
support mixing and matching weird combinations of slave ports (though
everybody does it). Then add some user interface to enter contents of
make.conf.

OPTIONS support is already on my todo since the very beginning but I 
have
no idea on when I will be able to work on that.

-- 
Bernhard Froehlich
http://www.bluelife.at/