In future, to replace autotools by cmake like KDE4 did?

In future, to replace autotools by cmake like KDE4 did?

[J.C. Pizarro]

The autotools ( automake + libtool + autoconf + ... ) generate many big
files that they have been slowing the building's computation and growing
enormously their cvs/svn/git/hg repositories because of generated files.

To see below interesting links:
1. http://dot.kde.org/1172083974/
2. http://sam.zoy.org/lectures/20050910-debian/
3. https://lwn.net/Articles/188693/
4. http://en.wikipedia.org/wiki/GNU_Build_Tools
5. http://en.wikipedia.org/wiki/GNU_Automake

The benefits could be:
* +40% faster in the KDE4 building vs KDE 3.5.6.
* elimination of redundant and unnecesary generated files as those
  from autotools.
* smaller cvs/svn/git/hg repositories.
* less errors/crashes when it's configuring.
* can be improved the cmake's sources for better performance's gain.
* good and long maintainance life.

I hope if the files for cmake+make can be well integrated in GCC 4.4

   J.C.Pizarro

Re: In future, to replace autotools by cmake like KDE4 did?

[Marcel Holtmann]

Hi,

> The autotools ( automake + libtool + autoconf + ... ) generate many  
> big
> files that they have been slowing the building's computation and  
> growing
> enormously their cvs/svn/git/hg repositories because of generated  
> files.
>
> To see below interesting links:
> 1. http://dot.kde.org/1172083974/
> 2. http://sam.zoy.org/lectures/20050910-debian/
> 3. https://lwn.net/Articles/188693/
> 4. http://en.wikipedia.org/wiki/GNU_Build_Tools
> 5. http://en.wikipedia.org/wiki/GNU_Automake
>
> The benefits could be:
> * +40% faster in the KDE4 building vs KDE 3.5.6.
> * elimination of redundant and unnecesary generated files as those
>  from autotools.
> * smaller cvs/svn/git/hg repositories.

stop spreading this FUD. If you leave the auto-generated files from  
autotools in the source control repositories, then it is your fault.  
They are generated files and can always be generated. Hence putting  
them under revision control makes no sense and so don't do it. And  
more certain don't complain about it if you did.

Regards

Marcel

Re: In future, to replace autotools by cmake like KDE4 did?

[Jakub Narebski]

"J.C. Pizarro" <jcpiza@gmail.com> writes:

> The autotools ( automake + libtool + autoconf + ... ) generate many big
> files that they have been slowing the building's computation and growing
> enormously their cvs/svn/git/hg repositories because of generated files.
[cut]

And this is relevant for this mailing list exactly how? From the whole
autotools package git uses only autoconf, and only as an optional part
to configure only Makefile configuration variables.

Generated files should not be put into version control, unless it is
for convenience only in separate branch like HTML and manpage versions
of git documentation are in 'html and 'man' branches, respectively.
The same could be done with ./configure script.

Although there was some talk about whether giw should use autotools,
or perhaps CMake, or handmade ./configure script like MPlayer IIRC,
instead of its own handmade Makefile...

-- 
Jakub Narebski
ShadeHawk on #git

Re: In future, to replace autotools by cmake like KDE4 did?

[Andreas Ericsson]

Jakub Narebski wrote:
> 
> Although there was some talk about whether giw should use autotools,
> or perhaps CMake, or handmade ./configure script like MPlayer IIRC,
> instead of its own handmade Makefile...
> 

To tell the truth, I'd be much happier if everything like that got
put in a header file or some such. 95% of what we figure out by looking
at "uname" output can already be learned by looking at the various
pre-defined macros.

Fortunately, there's a project devoted solely to this, so most of
the tedious research need not be done. It can be found at
http://predef.sourceforge.net/

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: In future, to replace autotools by cmake like KDE4 did?

[Jakub Narebski]

Andreas Ericsson wrote:
> Jakub Narebski wrote:
> > 
> > Although there was some talk about whether giw should use autotools,
> > or perhaps CMake, or handmade ./configure script like MPlayer IIRC,
> > instead of its own handmade Makefile...
> > 
> 
> To tell the truth, I'd be much happier if everything like that got
> put in a header file or some such. 95% of what we figure out by looking
> at "uname" output can already be learned by looking at the various
> pre-defined macros.
> 
> Fortunately, there's a project devoted solely to this, so most of
> the tedious research need not be done. It can be found at
> http://predef.sourceforge.net/

Code talks, bullsh*t walks.

Pre-defined macros cannot tell us if one have specific libraries
installed, cannot tell us if formatted IO functions support 'size
specifiers' even though compiler claim C99 compliance or even though
compiler doesn't claim C99 compliance but supports this, etc.

But perhaps the "uname" based compile configuration could be replaced
by testing pre-defined macros... at least for C code, and git is not
only C code.

-- 
Jakub Narebski
Poland

Re: In future, to replace autotools by cmake like KDE4 did?

[J.C. Pizarro]

On 2007/12/7, Jakub Narebski <jnareb@gmail.com> wrote:
> Andreas Ericsson wrote:
> > Jakub Narebski wrote:
> > >
> > > Although there was some talk about whether giw should use autotools,
> > > or perhaps CMake, or handmade ./configure script like MPlayer IIRC,
> > > instead of its own handmade Makefile...
> > >
> >
> > To tell the truth, I'd be much happier if everything like that got
> > put in a header file or some such. 95% of what we figure out by looking
> > at "uname" output can already be learned by looking at the various
> > pre-defined macros.
> >
> > Fortunately, there's a project devoted solely to this, so most of
> > the tedious research need not be done. It can be found at
> > http://predef.sourceforge.net/
>
> Code talks, bullsh*t walks.
>
> Pre-defined macros cannot tell us if one have specific libraries
> installed, cannot tell us if formatted IO functions support 'size
> specifiers' even though compiler claim C99 compliance or even though
> compiler doesn't claim C99 compliance but supports this, etc.
>
> But perhaps the "uname" based compile configuration could be replaced
> by testing pre-defined macros... at least for C code, and git is not
> only C code.
>
> --
> Jakub Narebski
> Poland
>

A powerful tool can do better things that old generators-based tools
(as autotools).

To imagine, there are many scripts in subdirectories or subprojects:

* Before: (many copy and paste of code as below paragraph)
A_VARIABLE_OS = `uname -a | grep .... `  # <- slow
case "$A_VARIABLE_OS" in
   *linux*) ... ;;
   *bsd*) ... ;;
   *aix*) ... ;;
   *) ...;;
esac
m4 foo.sh.m4 > bar.sh # <- very slow
./bar.sh

* Later: (with the powerful tool that had cached many predefined variables in
                   a ramdisk's file or in a daemon's memory)
# call once at 1st time to internal uname of powerful tool for all ocurrences of
# below predefined variable from many scripts:
case "$FOO_VARIABLE_OS" in
   *linux*) ... ;;
   *bsd*) ... ;;
   *aix*) ... ;;
   *) ...;;
esac
# i don't need to generate more scripts to inspect still more it.

   J.C.Pizarro

Re: In future, to replace autotools by cmake like KDE4 did?

[Marco Costalba]

On Dec 7, 2007 3:42 PM, J.C. Pizarro <jcpiza@gmail.com> wrote:
>
> A powerful tool can do better things that old generators-based tools
> (as autotools).
>
--- cut ---

>
> * Later: (with the powerful tool that had cached many predefined variables in

Insisting on highlighting your proposal as "powerful tool" vs what is
in git now (on which people spent long hours to tune it out) will give
you hard times on this list ;-)

Just my guess...

Marco

Re: In future, to replace autotools by cmake like KDE4 did?

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 2116 bytes --]

On Fri, Dec 07, 2007 at 15:42:31 +0100, J.C. Pizarro wrote:
> A powerful tool can do better things that old generators-based tools
> (as autotools).
> 
> To imagine, there are many scripts in subdirectories or subprojects:

No, there are not. There is just one. Multiple configuration scripts rarely
make sense.

> * Before: (many copy and paste of code as below paragraph)
> A_VARIABLE_OS = `uname -a | grep .... `  # <- slow
> case "$A_VARIABLE_OS" in
>    *linux*) ... ;;
>    *bsd*) ... ;;
>    *aix*) ... ;;
>    *) ...;;
> esac
> m4 foo.sh.m4 > bar.sh # <- very slow

Done once at release time.

> ./bar.sh
> 
> * Later: (with the powerful tool that had cached many predefined variables in
>                    a ramdisk's file or in a daemon's memory)

A daemon not runnin' here. No ramdisk here either. Freshly downloaded tarball
to an ancient Un*x with some quirky barely POSIX-compliant shell.

> # call once at 1st time to internal uname of powerful tool for all ocurrences of
> # below predefined variable from many scripts:
> case "$FOO_VARIABLE_OS" in

Someone had to create that variable. And there is just one way to: uname -a | ....

>    *linux*) ... ;;
>    *bsd*) ... ;;
>    *aix*) ... ;;
>    *) ...;;
> esac

And how exactly does this differ from the code you had above? For task that
runs once per installation (and for most users never, because their
distribution's build server runs it for them), it's simplicity of code that
matters.

> # i don't need to generate more scripts to inspect still more it.

And how exactly did you find, from the uname, whether I have libcrypto
installed? And whether I have it in /usr/lib, /opt/openssl/lib or
/usr/@foobar.com/sw/system/lib? How did you find libcurl, tcl, zlib...?

Besides, I inspected the configure.ac script that comes with git and it does
not actually contain any code like you show above. Git's configure script is
NOT looking at the platform name AT ALL. The makefile does, but that
obviously does not need anything generated by M4.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]