autogen.sh warnings

autogen.sh warnings

[Bruce Dubbs]

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

I did a fresh checkout of revision 1917 and autogen.sh produces several 
warnings, although the configure and make stages are OK.  I am using 
relatively new versions of autoconf and automake:

automake (GNU automake) 1.11
autoconf (GNU Autoconf) 2.64

When building, a lot of warnings is a red flag to me.  I've studied the 
code and am attaching the fixes.  autogen.sh now runs cleanly for me 
with a few informational messages.

Below are explanations of what was going on and attached are patches to 
remove all the warnings.

   -- Bruce


acinclude.m4:17: warning: underquoted definition of grub_PROG_TARGET_CC
acinclude.m4:17:   run info '(automake)Extending aclocal'
acinclude.m4:17:   or see 
http://sources.redhat.com/automake/automake.html#Extending-aclocal

This can be fixed by adding [] around AC_DEFUN values in acinclude.m4, 
e.g.:

AC_DEFUN(grub_PROG_TARGET_CC,

needs to be changed to

AC_DEFUN([grub_PROG_TARGET_CC],

-- 16 places.
-------------

configure.ac:42: warning: AC_ARG_PROGRAM was called before 
AC_CANONICAL_TARGET
../../lib/autoconf/general.m4:1839: AC_CANONICAL_TARGET is expanded from...
configure.ac:42: the top level
configure.ac:42: warning: AC_ARG_PROGRAM was called before 
AC_CANONICAL_TARGET
../../lib/autoconf/general.m4:1839: AC_CANONICAL_TARGET is expanded from...
configure.ac:42: the top level
configure.ac:42: warning: AC_ARG_PROGRAM was called before 
AC_CANONICAL_TARGET
../../lib/autoconf/general.m4:1839: AC_CANONICAL_TARGET is expanded from...
configure.ac:42: the top level
configure.ac:42: warning: AC_ARG_PROGRAM was called before 
AC_CANONICAL_TARGET
../../lib/autoconf/general.m4:1839: AC_CANONICAL_TARGET is expanded from...
configure.ac:42: the top level

This can be fixed by moving line

   AM_INIT_AUTOMAKE()

to right after the line  AC_CANONICAL_TARGET.
------------------

configure.ac:176: required file `./config.rpath' not found

The can be fixed by `touch config.rpath`
-----------------
automake: no `Makefile.am' found for any configure output

I created a one line Makefile.am with the contents:

SUBDIRS = . po

This also fixes a warning generated by AM_GNU_GETTEXT which needed to be 
changed to AM_GNU_GETTEXT([external]) to avoid a complaint about a 
missing intl/ directory.  Adding an empty ABOUT-NLS was also needed.
-----------------
WARNING: C file isn't a module: hash-common.c
WARNING: C file isn't a module: pubkey.c
WARNING: C file isn't a module: ecc.c
WARNING: C file isn't a module: elgamal.c
WARNING: C file isn't a module: hmac-tests.c
WARNING: C file isn't a module: md.c
WARNING: C file isn't a module: rsa.c
WARNING: C file isn't a module: ac.c
WARNING: C file isn't a module: dsa.c
WARNING: C file isn't a module: primegen.c
WARNING: C file isn't a module: cipher.c

These are generated by util/import_gcry.py by copying (and in some cases 
modifying) the files in lib/libgcrypt to lib/libgcrypt-grub. It also 
creates cipher.h, memory.h, and types.h.

The warnings above appear to be spurious for autogen.sh

I added code to util/import_gcry.py  supress the warnings if a third 
parameter is passed.  I then changed autogen.sh to use:

python util/import_gcry.py lib/libgcrypt/ . NoWarn

In a release, the lib/libgcrypt-grub/ directory should be released and 
the lib/libgcrypt/ should probably be suppressed to avoid dependence on 
ruby for non-developers.


[-- Attachment #2: autogen-errors.patch --]
[-- Type: text/plain, Size: 8718 bytes --]

=== added file 'ABOUT-NLS'
=== modified file 'ChangeLog'
--- ChangeLog	2009-12-06 09:20:01 +0000
+++ ChangeLog	2009-12-07 17:19:50 +0000
@@ -1,3 +1,18 @@
+2009-12-07 Bruce Dubbs <bruce.dubbs@gmail.com>
+
+   Remove spurious warnings when running autogen.sh.
+
+   * util/import_gcry.py: Add optional third parameter to supress spurious
+   warnings.
+   * autogen.sh: Add third parameter to invocation of util/import_gcry.py.
+   * acinclude.m4: Add quotes to underquoted variables.
+   * configure.ac: Move  AM_INIT_AUTOMAKE() to below AC_CANONICAL_TARGET
+   to supress warnings.  Also changed to AM_GNU_GETTEXT([external]).
+   * Makefile.am: Add one line file to supress spurious warnings.
+   * config.rpath: Add empty file to prevent complaint by automake.
+   * ABOUT-NLS: Add empty file wanted by AM_GNU_GETTEXT.
+
+
 2009-12-06 Felix Zielcke <fzielcke@z-51.de>
 
 	* util/misc.c (make_system_path_relative_to_its_root): Correctly cope with

=== added file 'Makefile.am'
--- Makefile.am	1970-01-01 00:00:00 +0000
+++ Makefile.am	2009-12-07 09:05:57 +0000
@@ -0,0 +1,1 @@
+SUBDIRS = . po 

=== modified file 'acinclude.m4'
--- acinclude.m4	2009-11-16 19:31:29 +0000
+++ acinclude.m4	2009-12-07 08:55:44 +0000
@@ -14,7 +14,7 @@
 
 
 dnl Check whether target compiler is working
-AC_DEFUN(grub_PROG_TARGET_CC,
+AC_DEFUN([grub_PROG_TARGET_CC],
 [AC_MSG_CHECKING([whether target compiler is working])
 AC_CACHE_VAL(grub_cv_prog_target_cc,
 [AC_LINK_IFELSE([AC_LANG_PROGRAM([[
@@ -36,7 +36,7 @@
 dnl compiling to assembler.
 dnl Written by Pavel Roskin. Based on grub_ASM_EXT_C written by
 dnl Erich Boleyn and modified by Yoshinori K. Okuji.
-AC_DEFUN(grub_ASM_USCORE,
+AC_DEFUN([grub_ASM_USCORE],
 [AC_REQUIRE([AC_PROG_CC])
 AC_MSG_CHECKING([if C symbols get an underscore after compilation])
 AC_CACHE_VAL(grub_cv_asm_uscore,
@@ -75,7 +75,7 @@
 
 dnl Some versions of `objcopy -O binary' vary their output depending
 dnl on the link address.
-AC_DEFUN(grub_PROG_OBJCOPY_ABSOLUTE,
+AC_DEFUN([grub_PROG_OBJCOPY_ABSOLUTE],
 [AC_MSG_CHECKING([whether ${OBJCOPY} works for absolute addresses])
 AC_CACHE_VAL(grub_cv_prog_objcopy_absolute,
 [cat > conftest.c <<\EOF
@@ -119,7 +119,7 @@
 
 dnl Supply --build-id=none to ld if building modules.
 dnl This suppresses warnings from ld on some systems
-AC_DEFUN(grub_PROG_LD_BUILD_ID_NONE,
+AC_DEFUN([grub_PROG_LD_BUILD_ID_NONE],
 [AC_MSG_CHECKING([whether linker accepts --build-id=none])
 AC_CACHE_VAL(grub_cv_prog_ld_build_id_none,
 [save_LDFLAGS="$LDFLAGS"
@@ -150,7 +150,7 @@
 dnl We only support the newer versions, because the old versions cause
 dnl major pain, by requiring manual assembly to get 16-bit instructions into
 dnl asm files.
-AC_DEFUN(grub_I386_ASM_ADDR32,
+AC_DEFUN([grub_I386_ASM_ADDR32],
 [AC_REQUIRE([AC_PROG_CC])
 AC_REQUIRE([grub_I386_ASM_PREFIX_REQUIREMENT])
 AC_MSG_CHECKING([for .code16 addr32 assembler support])
@@ -178,7 +178,7 @@
 
 dnl check if our compiler is apple cc
 dnl because it requires numerous workarounds
-AC_DEFUN(grub_apple_cc,
+AC_DEFUN([grub_apple_cc],
 [AC_REQUIRE([AC_PROG_CC])
 AC_MSG_CHECKING([whether our compiler is apple cc])
 AC_CACHE_VAL(grub_cv_apple_cc,
@@ -193,7 +193,7 @@
 
 dnl check if our target compiler is apple cc
 dnl because it requires numerous workarounds
-AC_DEFUN(grub_apple_target_cc,
+AC_DEFUN([grub_apple_target_cc],
 [AC_REQUIRE([AC_PROG_CC])
 AC_MSG_CHECKING([whether our target compiler is apple cc])
 AC_CACHE_VAL(grub_cv_apple_target_cc,
@@ -210,7 +210,7 @@
 dnl Later versions of GAS requires that addr32 and data32 prefixes
 dnl appear in the same lines as the instructions they modify, while
 dnl earlier versions requires that they appear in separate lines.
-AC_DEFUN(grub_I386_ASM_PREFIX_REQUIREMENT,
+AC_DEFUN([grub_I386_ASM_PREFIX_REQUIREMENT],
 [AC_REQUIRE([AC_PROG_CC])
 AC_MSG_CHECKING(dnl
 [whether addr32 must be in the same line as the instruction])
@@ -246,7 +246,7 @@
 
 dnl Older versions of GAS require that absolute indirect calls/jumps are
 dnl not prefixed with `*', while later versions warn if not prefixed.
-AC_DEFUN(grub_I386_ASM_ABSOLUTE_WITHOUT_ASTERISK,
+AC_DEFUN([grub_I386_ASM_ABSOLUTE_WITHOUT_ASTERISK],
 [AC_REQUIRE([AC_PROG_CC])
 AC_MSG_CHECKING(dnl
 [whether an absolute indirect call/jump must not be prefixed with an asterisk])
@@ -276,7 +276,7 @@
 
 dnl Check what symbol is defined as a bss start symbol.
 dnl Written by Michael Hohmoth and Yoshinori K. Okuji.
-AC_DEFUN(grub_CHECK_BSS_START_SYMBOL,
+AC_DEFUN([grub_CHECK_BSS_START_SYMBOL],
 [AC_REQUIRE([AC_PROG_CC])
 AC_MSG_CHECKING([if __bss_start is defined by the compiler])
 AC_CACHE_VAL(grub_cv_check_uscore_uscore_bss_start_symbol,
@@ -320,7 +320,7 @@
 
 dnl Check what symbol is defined as an end symbol.
 dnl Written by Yoshinori K. Okuji.
-AC_DEFUN(grub_CHECK_END_SYMBOL,
+AC_DEFUN([grub_CHECK_END_SYMBOL],
 [AC_REQUIRE([AC_PROG_CC])
 AC_MSG_CHECKING([if end is defined by the compiler])
 AC_CACHE_VAL(grub_cv_check_end_symbol,
@@ -352,7 +352,7 @@
 ])
 
 dnl Check if the C compiler generates calls to `__enable_execute_stack()'.
-AC_DEFUN(grub_CHECK_ENABLE_EXECUTE_STACK,[
+AC_DEFUN([grub_CHECK_ENABLE_EXECUTE_STACK],[
 AC_MSG_CHECKING([whether `$CC' generates calls to `__enable_execute_stack()'])
 AC_LANG_CONFTEST([[
 void f (int (*p) (void));
@@ -379,7 +379,7 @@
 
 \f
 dnl Check if the C compiler supports `-fstack-protector'.
-AC_DEFUN(grub_CHECK_STACK_PROTECTOR,[
+AC_DEFUN([grub_CHECK_STACK_PROTECTOR],[
 [# Smashing stack protector.
 ssp_possible=yes]
 AC_MSG_CHECKING([whether `$CC' accepts `-fstack-protector'])
@@ -398,7 +398,7 @@
 ])
 
 dnl Check if the C compiler supports `-mstack-arg-probe' (Cygwin).
-AC_DEFUN(grub_CHECK_STACK_ARG_PROBE,[
+AC_DEFUN([grub_CHECK_STACK_ARG_PROBE],[
 [# Smashing stack arg probe.
 sap_possible=yes]
 AC_MSG_CHECKING([whether `$CC' accepts `-mstack-arg-probe'])
@@ -414,7 +414,7 @@
 ])
 
 dnl Check if ln can handle directories properly (mingw).
-AC_DEFUN(grub_CHECK_LINK_DIR,[
+AC_DEFUN([grub_CHECK_LINK_DIR],[
 AC_MSG_CHECKING([whether ln can handle directories properly])
 [mkdir testdir 2>/dev/null
 case $srcdir in
@@ -432,7 +432,7 @@
 ])
 
 dnl Check if the C compiler supports `-fPIE'.
-AC_DEFUN(grub_CHECK_PIE,[
+AC_DEFUN([grub_CHECK_PIE],[
 [# Position independent executable.
 pie_possible=yes]
 AC_MSG_CHECKING([whether `$CC' has `-fPIE' as default])

=== modified file 'autogen.sh'
--- autogen.sh	2009-11-24 18:51:35 +0000
+++ autogen.sh	2009-12-07 09:31:59 +0000
@@ -11,7 +11,7 @@
 
 echo timestamp > stamp-h.in
 
-python util/import_gcry.py lib/libgcrypt/ .
+python util/import_gcry.py lib/libgcrypt/ . NoWarn
 
 for rmk in conf/*.rmk ${GRUB_CONTRIB}/*/conf/*.rmk; do
   if test -e $rmk ; then

=== added file 'config.rpath'
=== modified file 'configure.ac'
--- configure.ac	2009-12-05 10:08:26 +0000
+++ configure.ac	2009-12-07 09:05:44 +0000
@@ -32,7 +32,6 @@
 
 
 AC_INIT([GRUB],[1.97],[bug-grub@gnu.org])
-AM_INIT_AUTOMAKE()
 AC_PREREQ(2.60)
 AC_CONFIG_SRCDIR([include/grub/dl.h])
 AC_CONFIG_HEADER([config.h])
@@ -41,6 +40,8 @@
 AC_CANONICAL_HOST
 AC_CANONICAL_TARGET
 
+AM_INIT_AUTOMAKE()
+
 # Program name transformations
 AC_ARG_PROGRAM
 
@@ -173,7 +174,7 @@
 test "x$GCC" = xyes || AC_MSG_ERROR([GCC is required])
 
 AC_GNU_SOURCE
-AM_GNU_GETTEXT
+AM_GNU_GETTEXT([external])
 AC_SYS_LARGEFILE
 
 # Identify characteristics of the host architecture.

=== modified file 'util/import_gcry.py'
--- util/import_gcry.py	2009-11-17 10:22:54 +0000
+++ util/import_gcry.py	2009-12-07 09:17:04 +0000
@@ -26,18 +26,24 @@
     exit (0)
 indir = sys.argv[1]
 outdir = sys.argv[2]
+warn = True
+
+if len (sys.argv) > 3:
+   warn = False
 
 basedir = os.path.join (outdir, "lib/libgcrypt-grub")
 try:
     os.makedirs (basedir)
 except:
-    print ("WARNING: %s already exists" % basedir)
+    if warn:
+      print ("WARNING: %s already exists" % basedir)
 cipher_dir_in = os.path.join (indir, "cipher")
 cipher_dir_out = os.path.join (basedir, "cipher")
 try:
     os.makedirs (cipher_dir_out)
 except:
-    print ("WARNING: %s already exists" % cipher_dir_out)
+    if warn:
+      print ("WARNING: %s already exists" % cipher_dir_out)
 
 cipher_files = os.listdir (cipher_dir_in)
 conf = open (os.path.join (outdir, "conf", "gcry.rmk"), "w")
@@ -223,7 +229,8 @@
             conf.write ("%s_mod_CFLAGS = $(COMMON_CFLAGS) -Wno-missing-field-initializers -Wno-error\n" % modname)
             conf.write ("%s_mod_LDFLAGS = $(COMMON_LDFLAGS)\n\n" % modname)
         elif isc and cipher_file != "camellia.c":
-            print ("WARNING: C file isn't a module: %s" % cipher_file)
+            if warn:
+               print ("WARNING: C file isn't a module: %s" % cipher_file)
         f.close ()
         fw.close ()
         if nch:

Re: autogen.sh warnings

[Colin Watson]

On Mon, Dec 07, 2009 at 11:38:06AM -0600, Bruce Dubbs wrote:
> configure.ac:176: required file `./config.rpath' not found
>
> The can be fixed by `touch config.rpath`

configure does actually run this, so I'd recommend copying the file from
gettext or gnulib instead.

> automake: no `Makefile.am' found for any configure output
>
> I created a one line Makefile.am with the contents:
>
> SUBDIRS = . po
>
> This also fixes a warning generated by AM_GNU_GETTEXT which needed to be  
> changed to AM_GNU_GETTEXT([external]) to avoid a complaint about a  
> missing intl/ directory.  Adding an empty ABOUT-NLS was also needed.

This is likely to be delicate since we're not actually using Automake as
such, and we already have a separate Makefile.in which needs to not be
overwritten. I think adding a Makefile.am would make it just too easy to
clobber that by accident, even if it does suppress a warning message.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: autogen.sh warnings

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Bruce Dubbs wrote:
> I did a fresh checkout of revision 1917 and autogen.sh produces
> several warnings, although the configure and make stages are OK.  I am
> using relatively new versions of autoconf and automake:
>
> automake (GNU automake) 1.11
> autoconf (GNU Autoconf) 2.64
>
> When building, a lot of warnings is a red flag to me.  I've studied
> the code and am attaching the fixes.  autogen.sh now runs cleanly for
> me with a few informational messages.
>
> Below are explanations of what was going on and attached are patches
> to remove all the warnings.
>
Thanks. I'll let someone more familiar with automake to review automake
parts. Just a comment to import_gcry
>
> These are generated by util/import_gcry.py by copying (and in some
> cases modifying) the files in lib/libgcrypt to lib/libgcrypt-grub. It
> also creates cipher.h, memory.h, and types.h.
>
> The warnings above appear to be spurious for autogen.sh
crypto and experimental branches have newer import_gcry.py which has
less warning by skipping copying files unnecessary for grub2. If you
want to fix remaining warnings (on rsa, dsa, elgamal, primegen and ecc)
implement assymetric cryptography support (it's planned but may need
changes to core to be useful, there are lower hanging fruits for crypto).
>
> I added code to util/import_gcry.py  supress the warnings if a third
> parameter is passed.  I then changed autogen.sh to use:
>
> python util/import_gcry.py lib/libgcrypt/ . NoWarn
This NoWarn is just suppressing legitimate warnings
>
> In a release, the lib/libgcrypt-grub/ directory should be released and
> the lib/libgcrypt/ should probably be suppressed to avoid dependence
> on ruby for non-developers.
import_gcry.py is python, not ruby. Generally ./autogen.sh is ran before
releasing tarball


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: autogen.sh warnings

[Bruce Dubbs]

Colin Watson wrote:
> On Mon, Dec 07, 2009 at 11:38:06AM -0600, Bruce Dubbs wrote:
>> configure.ac:176: required file `./config.rpath' not found
>>
>> The can be fixed by `touch config.rpath`
> 
> configure does actually run this, so I'd recommend copying the file from
> gettext or gnulib instead.

The gettext version is a shell script about 670 lines long that is 
described:

# Output a system dependent set of variables, describing how to set the
# run time search path of shared libraries in an executable.

I'm not sure GRUB uses or needs the output of config.rpath.  I was just 
suppressing a warning.

>> automake: no `Makefile.am' found for any configure output
>>
>> I created a one line Makefile.am with the contents:
>>
>> SUBDIRS = . po
>>
>> This also fixes a warning generated by AM_GNU_GETTEXT which needed to be  
>> changed to AM_GNU_GETTEXT([external]) to avoid a complaint about a  
>> missing intl/ directory.  Adding an empty ABOUT-NLS was also needed.
> 
> This is likely to be delicate since we're not actually using Automake as
> such, and we already have a separate Makefile.in which needs to not be
> overwritten. I think adding a Makefile.am would make it just too easy to
> clobber that by accident, even if it does suppress a warning message.

You are probably right.  It looks like Makefile.in is basically 
destroyed.  Not good.  It looks like automake thinks it knows more than 
it's users and we'll have to live with the warning about missing 
SUBDIRS.  I think I could print out a message to ignore the spurious 
warning.

Do you want a new patch?

   -- Bruce

Re: autogen.sh warnings

[Bruce Dubbs]

Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> Thanks. I'll let someone more familiar with automake to review automake
> parts. Just a comment to import_gcry

>> These are generated by util/import_gcry.py by copying (and in some
>> cases modifying) the files in lib/libgcrypt to lib/libgcrypt-grub. It
>> also creates cipher.h, memory.h, and types.h.
>>
>> The warnings above appear to be spurious for autogen.sh

> crypto and experimental branches have newer import_gcry.py which has
> less warning by skipping copying files unnecessary for grub2. If you
> want to fix remaining warnings (on rsa, dsa, elgamal, primegen and ecc)
> implement assymetric cryptography support (it's planned but may need
> changes to core to be useful, there are lower hanging fruits for crypto).

I'm not following you completely.  I am trying to clean up the build 
environment, but not getting into the actual code.  I think the crypto 
was just recently merged into trunk, but I'm not knowledgeable about the 
details yet to make any substantive changes.

>> I added code to util/import_gcry.py  supress the warnings if a third
>> parameter is passed.  I then changed autogen.sh to use:

>> python util/import_gcry.py lib/libgcrypt/ . NoWarn

> This NoWarn is just suppressing legitimate warnings

Is a warning that you can't create a subdirectory because it already 
exists a legitimate warning?  The warning about files being copied not 
being modules seemed to be overkill.  Perhaps it could be left in and 
the WARNING changed to INFO.

>> In a release, the lib/libgcrypt-grub/ directory should be released and
>> the lib/libgcrypt/ should probably be suppressed to avoid dependence
>> on ruby for non-developers.

> import_gcry.py is python, not ruby. 

Yes, I mistyped that.

> Generally ./autogen.sh is ran before releasing tarball

Yes, but it's also run by someone new (like me) who may want to 
contribute.  The cleaner the better.

   -- Bruce

Re: autogen.sh warnings

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Bruce Dubbs wrote:
>
> I'm not sure GRUB uses or needs the output of config.rpath.  I was
> just suppressing a warning.
>
Just suppressing warning is a wrong approach. If warning is there it
usually means there is a reason for it. And the reason should be
corrected, we shouldn't just silence the warning. It's better to leave
the warning if you're unsure how to fix its reason.
> I think I could print out a message to ignore the spurious warning.
More output will only worse the situation.



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: autogen.sh warnings

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Bruce Dubbs wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
>> Thanks. I'll let someone more familiar with automake to review automake
>> parts. Just a comment to import_gcry
>
>>> These are generated by util/import_gcry.py by copying (and in some
>>> cases modifying) the files in lib/libgcrypt to lib/libgcrypt-grub. It
>>> also creates cipher.h, memory.h, and types.h.
>>>
>>> The warnings above appear to be spurious for autogen.sh
>
>> crypto and experimental branches have newer import_gcry.py which has
>> less warning by skipping copying files unnecessary for grub2. If you
>> want to fix remaining warnings (on rsa, dsa, elgamal, primegen and ecc)
>> implement assymetric cryptography support (it's planned but may need
>> changes to core to be useful, there are lower hanging fruits for
>> crypto).
>
> I'm not following you completely.  I am trying to clean up the build
> environment, but not getting into the actual code.  
Some warnings need code changes to be correctly fixed.
> I think the crypto was just recently merged into trunk, but I'm not
> knowledgeable about the details yet to make any substantive changes.
>
crypto isn't really in trunk, only libgcrypt import is. The crypto is in
crypto and experimental
>   The warning about files being copied not being modules seemed to be
> overkill.  
Such files are actually useless. And they (useless but copied files)
have to be warned about. This way we notice if new import has new
feature grub2 and/or import_gcry.py should be adjusted for. In
experimental only 5 files are still in this situation.
> Perhaps it could be left in and the WARNING changed to INFO.
This is a problem, not just INFO.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: autogen.sh warnings

[Colin Watson]

On Mon, Dec 07, 2009 at 02:28:19PM -0600, Bruce Dubbs wrote:
> Colin Watson wrote:
>> On Mon, Dec 07, 2009 at 11:38:06AM -0600, Bruce Dubbs wrote:
>>> configure.ac:176: required file `./config.rpath' not found
>>>
>>> The can be fixed by `touch config.rpath`
>>
>> configure does actually run this, so I'd recommend copying the file from
>> gettext or gnulib instead.
>
> The gettext version is a shell script about 670 lines long that is  
> described:
>
> # Output a system dependent set of variables, describing how to set the
> # run time search path of shared libraries in an executable.
>
> I'm not sure GRUB uses or needs the output of config.rpath.  I was just  
> suppressing a warning.

It is very likely to be incorrect to suppress a warning about a missing
executable by touching an empty file.

As I said, configure does use the output of config.rpath. You can verify
this for yourself by searching the configure script. Whether it makes a
practical difference probably depends on the platform.

>> This is likely to be delicate since we're not actually using Automake as
>> such, and we already have a separate Makefile.in which needs to not be
>> overwritten. I think adding a Makefile.am would make it just too easy to
>> clobber that by accident, even if it does suppress a warning message.
>
> You are probably right.  It looks like Makefile.in is basically  
> destroyed.  Not good.  It looks like automake thinks it knows more than  
> it's users

Automake's warning is pretty much correct, as it happens. GRUB is really
using it in a non-recommended way, but it is not at all straightforward
to either avoid using it (since the gettext build system rather likes
having it) or to use it properly (which involves a complete build system
revamp).

> and we'll have to live with the warning about missing  
> SUBDIRS.  I think I could print out a message to ignore the spurious  
> warning.
>
> Do you want a new patch?

Seems reasonable, yes.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: autogen.sh warnings

[Bruce Dubbs]

I've been looking at autogen.sh some more.

Does anyone know why the lines:

# FIXME: automake doesn't like that there's no Makefile.am
automake -a -c -f || true

are present at all?  Since there is no Makefile.am, it looks like 
automake only creates a few files and aborts.

Doing an experiment, I checked out a new version of trunk twice.  In 
both cases I ran md5sum on all the files in the top level directory.  In 
case 1, I didn't change anything and ran autogen.sh and then ran md5sum
again.  In case 2, I commented out the automake line above.

As you can see below, automake only adds standard 'config.guess', 
'config.sub', and 'missing' scripts.

The real purpose of automake is to create a Makefile.in for configure. 
GRUB doesn't use it for that.  Is there any reason to not just add the 
three files to the bzr repository and remove the automake line from 
autogen.sh?

Along with the other changes I proposed, it would create a really clean 
build process.

   -- Bruce

Case 1:

 > b30696711539bc73520a58a595d488d3  DISTLIST
10a12
 > 7e34eb2ddac5ca0b3a0852302ef0970d  aclocal.m4
11a14,17
 > f9410e9a94fc672046d4997ecf1b69c9  config.guess
 > 55061a86b93fd314344c7f41a9662db9  config.h.in
 > acb6cfae431c5ce7b2319cd668c86555  config.sub
 > 904614dd3a3ea6442432dba9b20062df  configure
25a32,34
 > 0afce91a3daa1fdc32ee36370c1129dd  install-sh
 > 6c12e662cd14b9b276338ec99c6ef3a7  md5sums
 > 9d9668fb32d0542b712be2c34ca79bd7  missing
26a36
 > 1ded054093de910d9786c62bc4fe8cc6  stamp-h.in

Case 2:

3a4
 > b30696711539bc73520a58a595d488d3  DISTLIST
10a12
 > 7e34eb2ddac5ca0b3a0852302ef0970d  aclocal.m4
12a15,16
 > 55061a86b93fd314344c7f41a9662db9  config.h.in
 > 904614dd3a3ea6442432dba9b20062df  configure
26a31
 > 29505be85d45d8a9b0a5fd3478ff6887  md5sums
27a33
 > 1ded054093de910d9786c62bc4fe8cc6  stamp-h.in

Re: autogen.sh warnings

[Bruce Dubbs]

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Bruce Dubbs wrote:
>> I'm not sure GRUB uses or needs the output of config.rpath.  I was
>> just suppressing a warning.

> Just suppressing warning is a wrong approach. If warning is there it
> usually means there is a reason for it. And the reason should be
> corrected, we shouldn't just silence the warning. It's better to leave
> the warning if you're unsure how to fix its reason.

I agree.  Please see my follow on message I sent a few minutes ago.  The 
underlying reason for the warning is using automake for a side effect 
and not its intended purpose.

   -- Bruce

Re: autogen.sh warnings

[Bruce Dubbs]

Colin Watson wrote:
> On Mon, Dec 07, 2009 at 02:28:19PM -0600, Bruce Dubbs wrote:
>> Colin Watson wrote:

> It is very likely to be incorrect to suppress a warning about a missing
> executable by touching an empty file.

> As I said, configure does use the output of config.rpath. You can verify
> this for yourself by searching the configure script. Whether it makes a
> practical difference probably depends on the platform.

Two things:

1.  GRUB doesn't have any config.rpath now, so configure can't use it. 
I only have x86 and x86_64 architectures, so it's possible that it could 
be installed on other platforms.

2.  Further analysis shows that I induced the warning when I incorrectly 
created Makefile.ac, so the issue should be moot.

   -- Bruce

Re: autogen.sh warnings

[Colin Watson]

On Mon, Dec 07, 2009 at 04:49:08PM -0600, Bruce Dubbs wrote:
> I've been looking at autogen.sh some more.
>
> Does anyone know why the lines:
>
> # FIXME: automake doesn't like that there's no Makefile.am
> automake -a -c -f || true
>
> are present at all?  Since there is no Makefile.am, it looks like  
> automake only creates a few files and aborts.
>
> Doing an experiment, I checked out a new version of trunk twice.  In  
> both cases I ran md5sum on all the files in the top level directory.  In  
> case 1, I didn't change anything and ran autogen.sh and then ran md5sum
> again.  In case 2, I commented out the automake line above.
>
> As you can see below, automake only adds standard 'config.guess',  
> 'config.sub', and 'missing' scripts.
>
> The real purpose of automake is to create a Makefile.in for configure.  
> GRUB doesn't use it for that.  Is there any reason to not just add the  
> three files to the bzr repository and remove the automake line from  
> autogen.sh?

These files do change from time to time, in ways that are important; for
example, config.guess and config.sub are updated to support new
architectures or new variants of existing architectures. It's best to
have this done automatically rather than doing it once manually and then
forgetting about it.

We could have a temporary directory in which we run automake, just for
the purpose of getting hold of these files. Perhaps something like this:

  rm -rf automake-tmp
  mkdir -p automake-tmp
  cat >automake-tmp/configure.ac <<EOF
AC_INIT([temporary], [0.1])
AC_CONFIG_AUX_DIR([.])
AM_INIT_AUTOMAKE
AC_CANONICAL_BUILD
AC_CONFIG_FILES([Makefile])
EOF
  touch automake-tmp/Makefile.am
  (cd automake-tmp && aclocal && automake -a -c -f --foreign)
  cp -a automake-tmp/config.guess automake-tmp/config.sub \
        automake-tmp/install-sh automake-tmp/missing \
        .
  rm -rf automake-tmp

I don't know whether this is worth it, but it would be possible.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: autogen.sh warnings

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Colin Watson wrote:
> On Mon, Dec 07, 2009 at 04:49:08PM -0600, Bruce Dubbs wrote:
>   
>> I've been looking at autogen.sh some more.
>>
>> Does anyone know why the lines:
>>
>> # FIXME: automake doesn't like that there's no Makefile.am
>> automake -a -c -f || true
>>
>> are present at all?  Since there is no Makefile.am, it looks like  
>> automake only creates a few files and aborts.
>>
>> Doing an experiment, I checked out a new version of trunk twice.  In  
>> both cases I ran md5sum on all the files in the top level directory.  In  
>> case 1, I didn't change anything and ran autogen.sh and then ran md5sum
>> again.  In case 2, I commented out the automake line above.
>>
>> As you can see below, automake only adds standard 'config.guess',  
>> 'config.sub', and 'missing' scripts.
>>
>> The real purpose of automake is to create a Makefile.in for configure.  
>> GRUB doesn't use it for that.  Is there any reason to not just add the  
>> three files to the bzr repository and remove the automake line from  
>> autogen.sh?
>>     
>
> These files do change from time to time, in ways that are important; for
> example, config.guess and config.sub are updated to support new
> architectures or new variants of existing architectures. It's best to
> have this done automatically rather than doing it once manually and then
> forgetting about it.
>
> We could have a temporary directory in which we run automake, just for
> the purpose of getting hold of these files. Perhaps something like this:
>
>   rm -rf automake-tmp
>   mkdir -p automake-tmp
>   cat >automake-tmp/configure.ac <<EOF
> AC_INIT([temporary], [0.1])
> AC_CONFIG_AUX_DIR([.])
> AM_INIT_AUTOMAKE
> AC_CANONICAL_BUILD
> AC_CONFIG_FILES([Makefile])
> EOF
>   touch automake-tmp/Makefile.am
>   (cd automake-tmp && aclocal && automake -a -c -f --foreign)
>   cp -a automake-tmp/config.guess automake-tmp/config.sub \
>         automake-tmp/install-sh automake-tmp/missing \
>         .
>   rm -rf automake-tmp
>
> I don't know whether this is worth it, but it would be possible.
>
>   
Why can't Makefile.in moved to Makefile.am and then just let automake
mostly copy Makefile.am to Makefile.in ? (I'm automake newbie), just an idea


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: autogen.sh warnings

[Bruce Dubbs]

Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> Why can't Makefile.in moved to Makefile.am and then just let automake
> mostly copy Makefile.am to Makefile.in ? (I'm automake newbie), just an idea

I've been invoking automake for years, but not writing for it.  I'll 
volunteer to try to make a proper Makefile.am.  No guarantees.

   -- Bruce

Re: autogen.sh warnings

[Colin Watson]

On Tue, Dec 08, 2009 at 01:01:28AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Why can't Makefile.in moved to Makefile.am and then just let automake
> mostly copy Makefile.am to Makefile.in ? (I'm automake newbie), just an idea

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

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Building system (Re: autogen.sh warnings)

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

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.



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

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

Re: autogen.sh warnings

[Felix Zielcke]

Am Montag, den 07.12.2009, 23:54 +0000 schrieb Colin Watson:
> > The real purpose of automake is to create a Makefile.in for
> configure.  
> > GRUB doesn't use it for that.  Is there any reason to not just add
> the  
> > three files to the bzr repository and remove the automake line
> from  
> > autogen.sh?
> 
> These files do change from time to time, in ways that are important;
> for
> example, config.guess and config.sub are updated to support new
> architectures or new variants of existing architectures. It's best to
> have this done automatically rather than doing it once manually and
> then
> forgetting about it.
> 

Well in the past I did sync config.guess and config.sub from the git
repository for them once in a while, when I noticed the changes for them
could be good for us.
So if people use outdated autotools it means a downgrade for them.


-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: autogen.sh warnings

[Robert Millan]

On Mon, Dec 07, 2009 at 07:21:28PM +0000, Colin Watson wrote:
> On Mon, Dec 07, 2009 at 11:38:06AM -0600, Bruce Dubbs wrote:
> > configure.ac:176: required file `./config.rpath' not found
> >
> > The can be fixed by `touch config.rpath`
> 
> configure does actually run this, so I'd recommend copying the file from
> gettext or gnulib instead.

config.{guess,sub} are automatically updated.  Can't config.rpath be
handled the same way?

In any case, this warning is harmless AFAICT.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: autogen.sh warnings

[Bruce Dubbs]

Robert Millan wrote:
> On Mon, Dec 07, 2009 at 07:21:28PM +0000, Colin Watson wrote:
>> On Mon, Dec 07, 2009 at 11:38:06AM -0600, Bruce Dubbs wrote:
>>> configure.ac:176: required file `./config.rpath' not found
>>>
>>> The can be fixed by `touch config.rpath`
>> configure does actually run this, so I'd recommend copying the file from
>> gettext or gnulib instead.
> 
> config.{guess,sub} are automatically updated.  Can't config.rpath be
> handled the same way?
> 
> In any case, this warning is harmless AFAICT.

Yes, it is harmless, but removing it is just more professional.  I don't 
have a problem with suppressing specific warnings if they have been 
considered and found inappropriate.

I'm pretty sure config.rpath only exists for ld.  There is is only used
when linking an ELF executable with shared objects.  Since GRUB doesn't 
create any libraries, then it is not appropriate.  An empty config.rpath 
is not unreasonable in this case.

config.guess, config.sub, missing, mkinstalldirs, and install-sh are 
only copied from /usr/share/automake-<version> as a part of automake. 
AFAICT, they are not used in GRUB.  I'm pretty sure they are the same on 
all architectures, but I could be wrong about that.

   -- Bruce

Re: autogen.sh warnings

[Felix Zielcke]

Am Mittwoch, den 09.12.2009, 16:19 -0600 schrieb Bruce Dubbs:
> config.guess, config.sub, missing, mkinstalldirs, and install-sh are 
> only copied from /usr/share/automake-<version> as a part of automake. 
> AFAICT, they are not used in GRUB.  I'm pretty sure they are the same
> on 
> all architectures, but I could be wrong about that. 

config.guess and config.sub are used by configure.
mkinstalldirs is used by the generated Makefile.
Looks like configure checks if install-sh is there but except of this it
isn't used.
missing isn't used because we don't use automake and maintainer mode.
-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: autogen.sh warnings

[Robert Millan]

On Wed, Dec 09, 2009 at 04:19:08PM -0600, Bruce Dubbs wrote:
> Robert Millan wrote:
>> On Mon, Dec 07, 2009 at 07:21:28PM +0000, Colin Watson wrote:
>>> On Mon, Dec 07, 2009 at 11:38:06AM -0600, Bruce Dubbs wrote:
>>>> configure.ac:176: required file `./config.rpath' not found
>>>>
>>>> The can be fixed by `touch config.rpath`
>>> configure does actually run this, so I'd recommend copying the file from
>>> gettext or gnulib instead.
>>
>> config.{guess,sub} are automatically updated.  Can't config.rpath be
>> handled the same way?
>>
>> In any case, this warning is harmless AFAICT.
>
> Yes, it is harmless, but removing it is just more professional.  I don't  
> have a problem with suppressing specific warnings if they have been  
> considered and found inappropriate.
>
> I'm pretty sure config.rpath only exists for ld.  There is is only used
> when linking an ELF executable with shared objects.  Since GRUB doesn't  
> create any libraries, then it is not appropriate.  An empty config.rpath  
> is not unreasonable in this case.

I wouldn't spend a lot of time with this.  If you think it's better to
remove the config.rpath warning, I don't mind.  If you find an easy way
to have autogen.sh update it, all the better.  I'd just like to avoid the
burden of perpetually updating this file by hand.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: autogen.sh warnings

[Bruce Dubbs]

Felix Zielcke wrote:
> Am Mittwoch, den 09.12.2009, 16:19 -0600 schrieb Bruce Dubbs:
>> config.guess, config.sub, missing, mkinstalldirs, and install-sh are 
>> only copied from /usr/share/automake-<version> as a part of automake. 
>> AFAICT, they are not used in GRUB.  I'm pretty sure they are the same
>> on 
>> all architectures, but I could be wrong about that. 
> 
> config.guess and config.sub are used by configure.

Called yes, and it will give errors if not present, but is the output 
used?  Looking at configure, I don't think so.

> mkinstalldirs is used by the generated Makefile.

It looks like a part of the generated install and dist targets.  Looking 
at the code of mkinstalldirs, it fundamentally does a mkdir -p.  It can 
change the permissions of the final directory, but that is not used by 
the Makefile.  It does do some cleanup for NextStep and OpenStep and 
makes sure that GNU mkdir is used on Sun.   The odds this will change in 
the future are very small.

> Looks like configure checks if install-sh is there but except of this it
> isn't used.

> missing isn't used because we don't use automake and maintainer mode.

Looks that way to me too.

   -- Bruce

P.S.  Some may ask why I am putting so much into the warnings generated 
by the build process.  There are a few reasons.  First, I feel that 
persistent warnings tend to make developers ignore ALL warnings and that 
makes it very easy to miss something relevant.  Second, it gives new 
developers a feeling that the original developers paid attention to 
details and will give confidence that the rest of the package is 
correct.  Third, it scratches an itch for me.  :)

Re: autogen.sh warnings

[Felix Zielcke]

Am Mittwoch, den 09.12.2009, 17:28 -0600 schrieb Bruce Dubbs:
> Felix Zielcke wrote:
> > Am Mittwoch, den 09.12.2009, 16:19 -0600 schrieb Bruce Dubbs:
> >> config.guess, config.sub, missing, mkinstalldirs, and install-sh
> are 
> >> only copied from /usr/share/automake-<version> as a part of
> automake. 
> >> AFAICT, they are not used in GRUB.  I'm pretty sure they are the
> same
> >> on 
> >> all architectures, but I could be wrong about that. 
> > 
> > config.guess and config.sub are used by configure.
> 
> Called yes, and it will give errors if not present, but is the output 
> used?  Looking at configure, I don't think so.

Just looking at the second result for searching config.guess in
configure makes it pretty clear for what they're used:

$SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
  as_fn_error "cannot run $SHELL $ac_aux_dir/config.sub" "$LINENO" 5

{ $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
$as_echo_n "checking build system type... " >&6; }
if test "${ac_cv_build+set}" = set; then :
  $as_echo_n "(cached) " >&6
else
  ac_build_alias=$build_alias
test "x$ac_build_alias" = x &&
  ac_build_alias=`$SHELL "$ac_aux_dir/config.guess"`
test "x$ac_build_alias" = x &&
  as_fn_error "cannot guess build type; you must specify one" "$LINENO" 5
ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias` ||
  as_fn_error "$SHELL $ac_aux_dir/config.sub $ac_build_alias failed" "$LINENO" 5
[...]
build=$ac_cv_build

The output of ./config.sub $(./config.guess) is used as build system
type, if you don't use --build option.


-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: autogen.sh warnings

[Robert Millan]

On Wed, Dec 09, 2009 at 05:28:21PM -0600, Bruce Dubbs wrote:
> Felix Zielcke wrote:
>> Am Mittwoch, den 09.12.2009, 16:19 -0600 schrieb Bruce Dubbs:
>>> config.guess, config.sub, missing, mkinstalldirs, and install-sh are  
>>> only copied from /usr/share/automake-<version> as a part of automake. 
>>> AFAICT, they are not used in GRUB.  I'm pretty sure they are the same
>>> on all architectures, but I could be wrong about that. 
>>
>> config.guess and config.sub are used by configure.
>
> Called yes, and it will give errors if not present, but is the output  
> used?  Looking at configure, I don't think so.

Yes.  All the checks that rely on ${host,target,build}_{os,cpu,vendor}
variables use those.

> P.S.  Some may ask why I am putting so much into the warnings generated  
> by the build process.  There are a few reasons.  First, I feel that  
> persistent warnings tend to make developers ignore ALL warnings and that  
> makes it very easy to miss something relevant.

Agreed.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: autogen.sh warnings

[Bruce Dubbs]

Felix Zielcke wrote:
> Am Mittwoch, den 09.12.2009, 17:28 -0600 schrieb Bruce Dubbs:
>> Felix Zielcke wrote:
>>> Am Mittwoch, den 09.12.2009, 16:19 -0600 schrieb Bruce Dubbs:

>>> config.guess and config.sub are used by configure.
>> Called yes, and it will give errors if not present, but is the output 
>> used?  Looking at configure, I don't think so.

> Just looking at the second result for searching config.guess in
> configure makes it pretty clear for what they're used:

> { $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
> $as_echo_n "checking build system type... " >&6; }
> if test "${ac_cv_build+set}" = set; then :
>   $as_echo_n "(cached) " >&6
> else
>   ac_build_alias=$build_alias
> test "x$ac_build_alias" = x &&
>   ac_build_alias=`$SHELL "$ac_aux_dir/config.guess"`
> test "x$ac_build_alias" = x &&
>   as_fn_error "cannot guess build type; you must specify one" "$LINENO" 5

> ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias` ||
>   as_fn_error "$SHELL $ac_aux_dir/config.sub $ac_build_alias failed" "$LINENO" 5
> [...]
> build=$ac_cv_build

OK, I see now what config.sub does and it is ultimately defining host_os 
and target_cpu used by grub in several .in files.

On the other hand, config.guess is used to get build_cpu and build_os 
and I don't see that being used at all right now by grub.

One thing I think we can agree on is that tracing through 
autoconf/automake generated files is not easy.  However, it's the only 
way I know of to really understand what is going on.  The autoconf 
manual really doesn't explain it very well, at least for me.  There are 
several tutorials and books on autotools, but none that I've seen go 
into the level of complexity required by grub.

   -- Bruce

Re: autogen.sh warnings

[Felix Zielcke]

Am Donnerstag, den 10.12.2009, 00:05 -0600 schrieb Bruce Dubbs:
> On the other hand, config.guess is used to get build_cpu and build_os 
> and I don't see that being used at all right now by grub. 

Well just after the part you quoted from me, I thought I made it clear
that the output of config.guess is used as an argument for config.sub
So you just need both. At least as long as autoconf doestn't get
changed.
-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: autogen.sh warnings

[Bruce Dubbs]

Felix Zielcke wrote:
> Am Donnerstag, den 10.12.2009, 00:05 -0600 schrieb Bruce Dubbs:
>> On the other hand, config.guess is used to get build_cpu and build_os 
>> and I don't see that being used at all right now by grub. 
> 
> Well just after the part you quoted from me, I thought I made it clear
> that the output of config.guess is used as an argument for config.sub
> So you just need both. At least as long as autoconf doestn't get
> changed.

Exactly.  I originally said that config.guess was required by configure 
even though the output not used.  As you pointed out to me, config.sub 
output is used.

This all goes back to the overall build process.  I've been thinking 
about it a lot, but I'm not ready to offer any suggestions yet.

   -- Bruce

Re: autogen.sh warnings

[Robert Millan]

On Thu, Dec 10, 2009 at 10:20:21AM -0600, Bruce Dubbs wrote:
> Felix Zielcke wrote:
>> Am Donnerstag, den 10.12.2009, 00:05 -0600 schrieb Bruce Dubbs:
>>> On the other hand, config.guess is used to get build_cpu and build_os 
>>> and I don't see that being used at all right now by grub. 
>>
>> Well just after the part you quoted from me, I thought I made it clear
>> that the output of config.guess is used as an argument for config.sub
>> So you just need both. At least as long as autoconf doestn't get
>> changed.
>
> Exactly.  I originally said that config.guess was required by configure  
> even though the output not used.  As you pointed out to me, config.sub  
> output is used.
>
> This all goes back to the overall build process.  I've been thinking  
> about it a lot, but I'm not ready to offer any suggestions yet.

What is exactly the problem?  Our use of config.{guess,sub} is pretty standard,
at least as far as invoking the scripts is concerned.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi

Re: autogen.sh warnings

[Bruce Dubbs]

Robert Millan wrote:
> On Thu, Dec 10, 2009 at 10:20:21AM -0600, Bruce Dubbs wrote:
>> Felix Zielcke wrote:
>>> Am Donnerstag, den 10.12.2009, 00:05 -0600 schrieb Bruce Dubbs:
>>>> On the other hand, config.guess is used to get build_cpu and build_os 
>>>> and I don't see that being used at all right now by grub. 
>>> Well just after the part you quoted from me, I thought I made it clear
>>> that the output of config.guess is used as an argument for config.sub
>>> So you just need both. At least as long as autoconf doestn't get
>>> changed.
>> Exactly.  I originally said that config.guess was required by configure  
>> even though the output not used.  As you pointed out to me, config.sub  
>> output is used.
>>
>> This all goes back to the overall build process.  I've been thinking  
>> about it a lot, but I'm not ready to offer any suggestions yet.
> 
> What is exactly the problem?  

Using automake without Makefile.am is non-standard and not provided for 
within automake.  The only thing we use automake for is to copy 
config.{guess,sub} to the root of the root of the source.

Also, building as one large monolithic Makefile with includes built via 
scripts is probably not optimal from a comprehension point of view.

> Our use of config.{guess,sub} is pretty standard,
> at least as far as invoking the scripts is concerned.

Yes, as we discussed, they are used in configure.

   -- Bruce

Re: autogen.sh warnings

[Robert Millan]

On Mon, Dec 28, 2009 at 09:50:47PM -0600, Bruce Dubbs wrote:
> Robert Millan wrote:
>>
>> What is exactly the problem?  
>
> Using automake without Makefile.am is non-standard and not provided for  
> within automake.  The only thing we use automake for is to copy  
> config.{guess,sub} to the root of the root of the source.
>
> Also, building as one large monolithic Makefile with includes built via  
> scripts is probably not optimal from a comprehension point of view.

That's a long-standing problem, with no easy solution.  But as for automake,
I don't think it'd be a bad idea to migrate Makefile.in to Makefile.am.  We
already have kludges in Makefile.in (e.g. docs/version.texi generation) which
would completely disappear if this file was automake'd.

Any takers?

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi

Re: autogen.sh warnings

[Bruce Dubbs]

Robert Millan wrote:
> On Mon, Dec 28, 2009 at 09:50:47PM -0600, Bruce Dubbs wrote:
>> Robert Millan wrote:
>>> What is exactly the problem?  
>> Using automake without Makefile.am is non-standard and not provided for  
>> within automake.  The only thing we use automake for is to copy  
>> config.{guess,sub} to the root of the root of the source.
>>
>> Also, building as one large monolithic Makefile with includes built via  
>> scripts is probably not optimal from a comprehension point of view.
> 
> That's a long-standing problem, with no easy solution. 

That's for sure.

> But as for automake,
> I don't think it'd be a bad idea to migrate Makefile.in to Makefile.am.  We
> already have kludges in Makefile.in (e.g. docs/version.texi generation) which
> would completely disappear if this file was automake'd.
> 
> Any takers?

I thought about it, but I really don't have much experience writing for 
autotools.  AFAICT, it would require getting rid of all the ruby and 
gen*.sh scripts and generally be very invasive.

As you know, GRUB supports many OSes, file systems, and BIOSes.  The 
nature of the process is closer to an operating system than a standard 
program.  The more I look at it, the more impressed I am that you guys 
get as much as you do working.

I think it would take many iterations to get an autotooled build system 
right.

   -- Bruce

Re: autogen.sh warnings

[Robert Millan]

On Fri, Jan 01, 2010 at 10:57:08AM -0600, Bruce Dubbs wrote:
>
> I thought about it, but I really don't have much experience writing for  
> autotools.  AFAICT, it would require getting rid of all the ruby and  
> gen*.sh scripts and generally be very invasive.

Well, yes.  But it's something we can assume  (btw note that most gen*
serve a very specific purpose and wouldn't be affected in any way).

> I think it would take many iterations to get an autotooled build system  
> right.

BVK had some interesting ideas about using multiple configure.ac like
other GNU projects (e.g. GCC) do.  He said he was going to investigate
this and try to make a prototype.  If you want to help, perhaps it'd be
a good idea to discuss it with him.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi

Re: autogen.sh warnings

[Robert Millan]

On Mon, Dec 07, 2009 at 06:13:33PM -0600, Bruce Dubbs wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
>> Why can't Makefile.in moved to Makefile.am and then just let automake
>> mostly copy Makefile.am to Makefile.in ? (I'm automake newbie), just an idea
>
> I've been invoking automake for years, but not writing for it.  I'll  
> volunteer to try to make a proper Makefile.am.  No guarantees.

Excellent.  I've just added a task for this:

  https://savannah.gnu.org/task/index.php?10063

If you're still interested, could you assign it to yourself?

Thanks!

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi