threads / discuss / 11169

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

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

## tl;dr

8 messages between Dec 7, 2007 and Dec 10, 2007.

replies: 7people: 6as markdown or json

J.C. Pizarro· Dec 7, 2007, 02:10 UTC · lore

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

Marcel Holtmann· Dec 7, 2007, 07:56 UTC · re: J.C. Pizarro · lore

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

Hi,

Show 19 quoted lines

> 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

Jakub Narebski· Dec 7, 2007, 12:14 UTC · re: J.C. Pizarro · lore

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

"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

Andreas Ericsson· Dec 7, 2007, 12:44 UTC · re: Jakub Narebski · lore

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

Jakub Narebski wrote:

Show 5 quoted lines

> 
> 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

Jakub Narebski· Dec 7, 2007, 13:56 UTC · re: Andreas Ericsson · lore

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

Andreas Ericsson wrote:

Show 15 quoted lines

> 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

J.C. Pizarro· Dec 7, 2007, 14:42 UTC · re: Jakub Narebski · lore

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

On 2007/12/7, Jakub Narebski <jnareb@gmail.com> wrote:

Show 32 quoted lines

> 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

Marco Costalba· Dec 7, 2007, 16:10 UTC · re: J.C. Pizarro · lore

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

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

Jan Hudec· Dec 10, 2007, 20:23 UTC · re: J.C. Pizarro · lore

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

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.

Show 9 quoted lines

> * 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 | ....

Show 5 quoted lines

>    *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>