Choosing a new build system for Samba

[Stefan (metze) Metzmacher]

tridge at samba.org schrieb:
> Hi Andrew,
> 
>  > Clearly there is a very real waf proposal.  Tridge has it on a build
>  > farm host already
>  > http://build.samba.org/?tree=samba_4_0_waf&compiler=cc&function=Recent
>  > +Builds and has it passing almost all of 'make test'.  The wiki page is
>  > at http://wiki.samba.org/index.php/Waf
> 
> A minor update - it is passing 'make test' on some boxes now. I put it
> on the build farm as samba_4_0_waf a few hours ago, and of course
> found plenty of problems. I'll look at those over the next few days. 
> 
>  > If we maintain the existing system, who will maintain it?  
>  > ---------------------------------------------------------
>  > Should we maintain any new build system in parallel, or will we have a
>  > 'flag day' that we switch on?
>  > 
> 
> I'm in favour of a staged transition. I would imagine the stages would
> be:
> 
>   stage 1) get it working reasonably in a separate branch. For the waf
>            effort this is my waf-wip branch, and I suspect it will
>            reach this stage for s4 in the next week or so.
> 
>   stage 2) when it looks good and the team agrees, then merge it to
>            master, but ensuring it changes zero files that impact on
>            the existing build system (the waf-wip branch now does
>            this). At this stage maintainence of the new build system
>            in master would be the responsibility of those who have the
>            enthusiasm to do it. The old build system would still be
>            the one we recommend to users, and Samba developers who are
>            not interested in the new build system would have no
>            obligation to update the new build scripts for any changes.
> 
>   stage 3) once the proponents of the new build system think it is
>            sufficiently good, then they would propose changing the
>            default build system to the new one. We'd discuss this
>            within the team and the wider community and decide if we
>            would go ahead. If it is decided to change the default then
>            the maintainence obligation of developers would switch to
>            the new build scripts. The old build scripts would be
>            maintained by whoever volunteers to maintain them.
> 
>   stage 4) if we get to the stage that nobody is willing to maintain
>            the old build scripts any more then we could remove them
>            from the tree.
> 
> I don't know how long each of these stages might take. I'd guess that
> the waf effort will get to the end of stage 1 for Samba4 in the next
> week or so, but I won't really know till it's done, as I may still run
> across a problem that is hard to fix. I'd certainly like it to reach
> that stage before SambaXP.
> 
> The other factor is how these stages interact with the s3/s4/merged
> builds. I think it might be reasonable to have those 3 reach different
> stages at different times. For the waf effort Kai is starting on the
> s3 build, but if that takes a while then I don't think it would be
> unreasonable for the s4 build process to go to stage 2 before the s3
> build has gotten to the end of stage 1. I could even imagine gettng
> the s4 build to stage 4 (where the old s4 build system is deleted)
> before the s3 build with a new system is working. I don't think it is
> likely to happen that way, but I don't think it is something we have
> to necessarily avoid.
>
> I agree with Andrew that we should try and move to a common build
> system, and I'd hope that in a years time we can share modules between
> s3 and s4 more easily as their build rules will be in common, but I
> don't think a "flag day" is the way to do. I hope the above staged
> approach is a good alternative.

I like the staged approach.

And I hope the 5th stage is to only build everthing via one build system
from the toplevel directory. So that every developer build and tests
everything by default.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100319/1d5c1fe1/attachment.pgp>