[PROPOSAL] To retire autoconf for 4.1

[C.J. Adams-Collier KF7BMP]

Hey there Andrew, list,

Speaking as a build engineer responsible for compiling samba to run on
hundreds of systems, I would personally prefer not to phase autotools
out.  Many distributions assume that there is an autoreconf
-i ; ./configure ; make ; make install option available in software they
build for their platforms, and build engineers know the system well
enough to produce binaries.  Forcing build engineers to learn something
new will delay and in some cases remove support entirely for samba on
many platforms.

In the past, I've needed to provide alternate build options to various
communities and have contributed code to a project called 'Prebuild'
which takes build definitions from an XML file and generates various
other formats.  Although this worked in most cases, it was cumbersome
and error prone.

I understand that many folks feel that m4, libtool, automake, autoconf,
etc. are also cumbersome and error prone, but they get the job done
using an interface that has become customary in the unix build world.
Build systems already have auto* deployed to them and do not require
testing and review to ensure that they do what they are expected to do.

So, my 2¢ is this:
1) autotools should remain the primary environment probing /
configuration system
2) failing that, it should remain an equal first class participant along
with the new alternative
3) failing that, build definitions should be stored in an easy-to-parse
file and used to generate an autotools as well as other build systems

Cheers,

C.J.
IMHO, IANAL, IDDQD


On Tue, 2013-05-21 at 19:08 +1000, Andrew Bartlett wrote:

> G'day,
> 
> Michael Adam tells me he raised this in brief at SambaXP, but I wanted
> to bring it up here:
> 
> As we consider dates for Samba 4.1, I think it's finally time to have
> a discussion about removing autoconf.  I know this is controversial in some circles, so
> I have avoided starting this discussion for some time.  
> 
> Delaying this proposal has been useful, because in the almost 6 months since we
> released Samba 4.0, I've seen vanishingly few complaints about our waf
> build system.  Indeed, the users who seem to admire it most are those on
> the old Solaris systems, because they say it handles the use of
> non-system OpenLDAP libs better, and provides a modern kerberos
> bundled-in!
> 
> I've personally worked with a Solaris 8 site with the (sensible, for a
> system of that age) requirement that it not be directly connected to the
> internet, and it is from working with that user that the
> build_with_python.sh script was improved.
> 
> I'm not going to say that waf is perfect - it certainly isn't, but for
> Samba 4.1 and beyond, we should focus our energies on a single build
> system, and making it better, rather than continuing to build this large
> and complex code base with two independent build systems that we have to
> keep in sync.
> 
> The autoconf build system has supported us for a long time, but just as
> it is time that we retire SWAT, Samba 4.1 is the appropriate time to
> retire autoconf, and move to a single way to build a unified Samba
> project. 
> 
> That we are making a Samba 4.1 release without major feature upgrades
> makes this a particularly good opportunity, as users who might be
> adversely impacted (and not have noticed any of our previous list
> announcements, or BUILD_SYSTEMS.txt) will almost certainly be able to
> use Samba 4.0 as a fall-back. 
> 
> I'm sure many of you will have comments, and I fully acknowledge that
> the way waf was brought to Samba was not a pleasant process for any of
> us.  I hope that despite that pain we can still make a decision here.
> 
> Some background on the long slog to ensure config.h files match can be found in:
> https://bugzilla.samba.org/show_bug.cgi?id=8969
> 
> Thanks,
> 
> Andrew Bartlett


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20130522/7e4dd1b3/attachment.pgp>