Choosing a new build system for Samba

[Stefan (metze) Metzmacher]

Hi Andrew,

> Is there any objection to the idea of moving to a new build system?
> -------------------------------------------------------------------
> 
> I'm particularly asking this question to those of my fellow team members
> who work primarily on Samba3.  Any new build system will need to be for
> the whole of Samba, or else we move backwards from our commitment to a
> combined Samba 4.0.  In particular the merged build gives a quite
> delicate dependency between Samba3 and Samba4.

I think a new build system would really help to move Samba3 and Samba4
more closely together.

> 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?
> 
> The reason I ask is that I'm worried that any second system (either the
> new or old one, depending on popularity) would bitrot quickly and add to
> the testing matrix.  But a parallel move would make it much easier for
> developers to adjust to the new system (whichever is chosen) in the
> short term. 
> 
> 
> What must a new system do?
> --------------------------
> Aside from the things Tridge listed in
> http://lists.samba.org/archive/samba-technical/2010-February/069716.html
> what additional requirements are there for a new build system?  I'm just
> worried that we don't have a good yardstick by which to measure it,
> other than 'must do what the old one did'.  
> 
> What particular things does the current system (particularly the Samba3
> system) do, that a new system must also do?  What things does the
> current system do, that a new system need not do?
> 
> 
> What are the benefits of a new build system?
> --------------------------------------------
> 
> The reason we hack Samba is to improve it, and while change is hard, it
> also brings new opportunities.  I would like to see a little more
> written about what a new build system would allow.  (I know I've heard a
> lot about waf in private conversations, but that's not a good way for us
> all to hear).
> 
> In particular, I would like to hear about how any new system would make
> it easier to merge code between Samba3 and Samba4, and make the merged
> build less special.  

I think a new build system needs to support automatic dependencies
(while making the build still be 100% reliable).

=> 'make clean' should be history. We have (at least I had) wasted
   so many time waiting for a rebuild or debugging segfaults
   because if inconsistent builds.

Then we'll have much less overhead in making the merged build the
default. And we'll have more time working on real code.

The waf-wip branch is on a good way to provide the automatic depency
support, there's even a rule that pidl generated files are regenerated
when pidl itself has changed. Waf has also a builtin ccache like cache
support, which will also reduce the build overhead (this feature needs
a bit more work (size limit)).

> How will we decide?
> -------------------
> 
> Even if we decide to use two systems in parallel for a time, how will we
> decide to actually make the switch?  I think this is something the whole
> team needs to accept and adopt - because we all need to be willing to
> use and work with the new system for a very long time.  
> 
> My worry is that if we don't evaluate the build systems on their merits,
> and then live with our decisions, we risk later recriminations based on
> hindsight.  No Samba developer deserves that fate. 

Yep, we need to careful and have a lot of patience before we'll do a
possible final switch.

A new build system should make the life easier for all developers in the
next years...

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/ef4db263/attachment.pgp>