autogen questions

[Neil Williams]

On Friday 18 November 2005 10:17 am, Christian Stimming wrote:
> Hi Neil,

I'm not sure I've pinned down the reasons for the problems I had with the 
script - I suspect that more issues were fixed by changing the default path 
on OSX than I suspected. In particular, I have had lots of problems with the 
installed version of libtool being located before the GNU libtool from fink. 
The same thing happened with sed (shown by the tip_of_the_day problems). Both 
were fixed with the PATH change.

What I found useful with the old script was mainly libtool, rather than 
autotools handling - the fact that the libtool --version command fails 
with /usr/bin/libtool (because it's BSD) means the build halts earlier and 
gives a chance to fix things.

The improved script simply hid all this within standard macros and made it 
hard to work out what had gone wrong. 

My basic problem was probably in my OSX build environment itself. The new 
script highlighted the problem but hid useful information on how to detect 
and fix it.

Thomas' guile16-build env command has proved vital.

Together, these explain my problems with not getting the correct tools 
detected with the new script.

> I'll reconsider the autogen.sh simplification soon.

OK, all I can say at this stage is that it'd be good to check for and conflict 
with automake1.4 if possible. That was the source of my Debian problem and it 
also affected OSX. How do we conflict with automake1.4 before configure is 
written?

> In order to provide 
> you with the necessary directions for a simplified autogen on Mac OSX,
> I'd need some version numbers from you.

Note that the Apple libtool and sed commands from BSD do not have --version 
options, they print usage to stderr instead. We need the fink version of sed 
for tip_of_the_day and the fink version of libtool throughout the build. It 
would be good to check for a usable --version option as a means of 
identifying a usable libtool and sed. This has always been about more than 
just the autotools.

> What does the following give as version numbers in your normal build
> environment?

Note that this is now the fixed environment. In each case, /usr/bin indicates 
the default Apple/BSD version and if we end up using that, the build is 
v.likely to break. Under the old script, it broke later but more noisily. 
With the new script, it broke silently and left me with no idea what had gone 
wrong.

>   autoconf --version | head -1

$ /usr/bin/autoconf --version | head -1
autoconf (GNU Autoconf) 2.57
$ /sw/bin/autoconf --version | head -1
autoconf (GNU Autoconf) 2.59

>   autoheader --version | head -1

$ /usr/bin/autoheader --version | head -1
autoheader (GNU Autoconf) 2.57
$ /sw/bin/autoheader --version | head -1
autoheader (GNU Autoconf) 2.59

>   automake --version | head -1

$ /usr/bin/automake --version | head -1
automake (GNU automake) 1.6.3
$ /sw/bin/automake --version | head -1
automake (GNU automake) 1.9.5

>   aclocal --version | head -1

$ /usr/bin/aclocal --version | head -1
aclocal (GNU automake) 1.6.3
$ /sw/bin/aclocal --version | head -1
aclocal (GNU automake) 1.9.5

> And what are the actually used autotool versions during your gnucash
> build, to be found out as follows:

With the fink path set at the beginning of the PATH variable:
(/sw/bin must be before /usr/bin)

>   grep generated configure | head -1

SVN: generated by GNU Autoconf 2.59. Invocation command line was
Old CVS: generated by GNU Autoconf 2.59

>   head -1 config.h.in   #(unfortunately probably without version number)

SVN: /* config.h.in. Generated from configure.in by autoheader. */
Old CVS: /* config.h.in. Generated from configure.in by autoheader. */

>   grep generated Makefile.in | head -1

SVN: # Makefile.in generated by automake 1.9.5 from Makefile.am.
Old CVS: # Makefile.in generated by automake 1.9.5 from Makefile.am.

>   grep generated aclocal.m4 | head -1

SVN: # aclocal.m4 generated automatically by aclocal 1.9.5 -*- Autconf -*-
CVS: # aclocal.m4 generated automatically by aclocal 1.9.5 -*- Autconf -*-

With the fink path given at the end of the PATH variable:
config.h.in is unchanged and configure is not touched with the SVN build from 
r11855. 

If we can just get an error message at this point, I'd be happy. Maybe we 
could check for the existence of configure (or a recent timestamp) before we 
advise to run it!
:-)

There are other warnings that appear, to do with the use of SUBDIRS being 
already defined. 

>   grep generated configure | head -1

Old CVS: generated by GNU Autoconf 2.57

>   grep generated Makefile.in | head -1

SVN: # Makefile.in generated by automake 1.6.3 from Makefile.am.
CVS: # Makefile.in generated by automake 1.6.3 from Makefile.am.

>   grep generated aclocal.m4 | head -1

SVN: # aclocal.m4 generated automatically by aclocal 1.6.3 -*- Autconf -*-
CVS: # aclocal.m4 generated automatically by aclocal 1.6.3 -*- Autconf -*-

> Thanks for providing this information. I'll send a test autogen.sh with
> my proposed instructions for Mac OSX to you privately before I commit to
> SVN.

That would be helpful, thank you.

If we can conflict with automake1.4 and print an error message if configure is 
not touched, (along the lines of "please check the build instructions for 
your platform in doc/build-..."), I think it'll work.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20051118/2921c31a/attachment.bin