Fw: [PROPOSAL] To retire autoconf for 4.1

[C.J. Adams-Collier KF7BMP]

On Fri, 2013-05-24 at 10:25 +0200, Michael Adam wrote:
> On 2013-05-23 at 17:49 -0700, C.J. Adams-Collier KF7BMP wrote:
> > On Fri, 2013-05-24 at 02:07 +0200, Jelmer Vernooij wrote:
> > > If there are regressions or concrete concerns, by all means,
> > > please bring them up and we can discuss them. 
> > > 
> > > Cheers,
> > > 
> > > Jelmer 
> > 
> > Okay.  You've convinced me.  But I reserve the right to say "I told you
> > so" ;-)
> 
> As Jelmer pointed out, the fundamental discussion you are
> starting here has been (or should have been) taken place
> several years ago.
> 
> We have been building the AD-Part (samba4) of Samba with waf for more
> than three years now (iirc), the combined build followed soon.
> And before introducing waf, the samba4 part was also not built by
> a (pure) autoconf system for a considerable time.
> 
> What we are talking about now is the question whether to remove
> the autoconf build system from the source3 subdirectory,
> which is also built with the top level waf build, which is
> declared default build in in Samba 4.0.
> 
> So maybe you should have told us several years ago. :-)
> 
> Cheers - Michael

Yes, I agree.  But I haven't been trolling this list for very long.

My concern is that there are probably many use cases which the autoconf
build environment is unwittingly making functional.  Many folks tend to
complain about build problems in hallways at conferences and directly to
folks who can make changes to the environment directly.  Some build
folks who might have had commit access to the source might have patched
things up without reporting bugs.  Some issues might have been addresses
in other packages and fixed in autoconf before they reared their head in
samba specifically.

I'm just saying that there are likely a lot of edge cases which are
being made possible through the use of this time tested and hardened
system.  Be aware that some folks may submit regression reports so that
they can be addressed, but in many cases, those reports won't get filed
and user adoption will instead diminish silently.

If I had more time to dedicate to the project, I would maintain an
alternate branch with an autoconf build system.  But I don't, and I
trust that the Samba Team™ will continue to run a tight ship, so I'll
just be a curmudgeon and mumble about how back in my day we used
autoconf and it worked just fine for us.

Cheers,

C.J.

ps

> On Fri, 2013-05-24 at 02:07 +0200, Jelmer Vernooij wrote:
> Either way, I don't see how the age of the technology matters other than
> as a rough indicator of its maturity. The technologies the old and the new
> build system were built on (Python and autoconf) both date from '91.

you be frontin'.  autoconf is built on m4 and the bourne shell (both
from 1977).  waf may be built on Python, but the first commit to its
current source tree happened in 2011.

        cjac at foxtrot:/usr/src/git/google/waf$ git log | tail
        Author: Thomas Nagy <tnagy2pow10 at gmail.com>
        Date:   Sat Sep 10 12:20:18 2011 +0200
        
            Unused variable
        
        commit 44a967e326cc2e670a31b3712e4763b72d65e81b
        Author: Thomas Nagy <tnagy2pow10 at gmail.com>
        Date:   Sat Sep 10 11:13:51 2011 +0200
        
            Initial commit

Looks like the first commits to the present autoconf tree happened in
1992.  On a Sunday.  At 06:30 hrs.  By a guy who still uses the same
email address twenty years later.

        cjac at foxtrot:/usr/src/git/savannah/autoconf$ git log | tail
        Author: Richard M. Stallman <rms at gnu.org>
        Date:   Fri Mar 13 19:54:03 1992 +0000
        
            Initial revision
        
        commit c05d1676aafc5afd689b7dc304e622450c33a450
        Author: Richard M. Stallman <rms at gnu.org>
        Date:   Sun Mar 8 06:28:22 1992 +0000
        
            Initial revision

-------------- 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/20130529/6d000eae/attachment.pgp>