Re: Building system (Re: autogen.sh warnings)

[Bruce Dubbs]

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Colin Watson wrote:
> > I wouldn't recommend it. The syntax looks similar, but there are some
> > slight differences, and Automake has its own ideas of what rules and
> > variables you are and aren't allowed to override. Besides, there's quite
> > a lot of stuff that Automake will output even with an entirely blank
> > Makefile.am; I doubt it would be very much fun to try to merge that into
> > the current Makefile.in without essentially doing a full port to
> > Automake.
> >
> > (Now if only I had time to actually do such a port ...)

> You may consider this mail:
> http://lists.gnu.org/archive/html/grub-devel/2006-08/msg00017.html
> I see following variants for future developpement:
> - Keep ruby and improve it to address some of its deficiencies
> - Rewrite system in python. This way merging ruby and python dependencies.
> - Using automake if it's deficiencies are addressable
> - Using just GNU make as I proposed and implemented once.

That is an interesting email from 2006.  It looks like this issue has 
been around for quite a while.

What is there right now seems to be a combination of items 1, 2, and 3. 
 I've spent some time this evening reviewing automake and autoconf and 
it appears that they are not appropriate for GRUB as the only build 
tool.  For one thing, GRUB creates no libraries, but it does create a 
lot of specialized modules that respond in some ways like dynamic 
libraries, but because of the specialized nature of the boot process, 
have to be implemented and built in a specialized way.

Using multiple tools to control the build process is difficult and error 
prone.  Either ruby or python would do, but I would note that python is 
a part of the Linux Standards Base Runtime Languages specification and 
ruby is not.  On the other hand, there is a lot less python code.

There are also the shell script files to consider, however they are
fairly short and most have about 12 lines of copyright info in them 
(there are no copyright headers in the .rmk files).

The current configuration contains the following line count:

  443 genmk.rb

   89 conf/any-emu.rmk
  634 conf/common.rmk
   97 conf/gcry.rmk
  206 conf/i386-coreboot.rmk
  164 conf/i386-efi.rmk
  145 conf/i386-ieee1275.rmk
  385 conf/i386-pc.rmk
    2 conf/i386-qemu.rmk
   21 conf/i386.rmk
  111 conf/powerpc-ieee1275.rmk
  136 conf/sparc64-ieee1275.rmk
  169 conf/x86_64-efi.rmk

  286 util/import_gcry.py

   23 genhandlerlist.sh
   26 genpartmaplist.sh
   47 genmodsrc.sh
   77 gensymlist.sh
   23 autogen.sh
   75 geninit.sh
   45 gendistlist.sh
   27 genkernsyms.sh
    4 efiemu/runtime/efiemu.sh
   26 genfslist.sh
   22 gencmdlist.sh
   45 geninitheader.sh
   19 genparttoollist.sh


What autotools does offer is a standard way to control installation 
directories, selective tool building, and tests for prerequisite tools, 
but those requirements should not need to be changed frequently.  A 
custom Makefile and/or configure with include files generated from 
python or ruby seems to be a reasonable approach.

I'm willing to help and can use any of these tools with varying amount 
of initial experience.  Right now, I do not have strong thoughts about 
the way to go, but feel that the status quo is not optimal in the long run.

The above data is meant only to further discussion.

  -- Bruce