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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
