Radically improve autogen.sh - cannot build trunk.

[Neil Williams]

On Sunday 06 November 2005 1:54 pm, Christian Stimming wrote:
(inadvertently sent off-list - new copy for the list)

> sorry that it's you again who runs into all kinds of trouble with this
> change. 

AFAICT I'm the only one developing on OSX and the only one developing on 
Debian unstable. Both are "progressive" rather than "frozen" installations - 
rolling library versions ever onwards. Debian unstable is never frozen so 
there's no "break" as there is between FC3 and FC4. Fink follows the same 
model and gnucash needs to avoid all the OSX code it can - the BSD code in 
OSX stinks!

(IMHO BSD in OSX == bull s**t development)

> Then main discussion of that change happened on IRC

I hate IRC - it's all the things I dislike about the telephone with none of 
the benefits of email. It's intrusive (you have to be online when others are 
online), it's invasive (it interrupts me in the middle of other things 
instead of waiting until I'm ready) and it's non-archived (so nobody can 
catch up with the IRC thread).

It might be half-usable if there was a public archive of ALL gnucash IRC 
conversations but even that is not particularly useful because there's no way 
of breaking the logs into logical conversations.

> occasionally  
> during the last weeks, so I assumed that after cleaning up this script good
> enough then it should work for all circumstances. 

Making an assumption based on a GNU environment does not mean you can expect 
it to work in a non-GNU environment. OSX is non-GNU and needs to be beaten 
into submission before it will behave in a GNU manner. Even then, there are 
surprises. n.b. assumption is the mother of all foulups. (And I've made 
enough!)
:-)

> * As for ./autogen.sh calling ./configure: autogen and configure are two
> orthogonal things; autogen is meant *only* for creating the helper stuff
> when you got your code from CVS^H^H^H SVN, whereas configure is meant for
> each and every built, regardless whether is came from SVN or from a
> tarball. Having autogen.sh automatically calling configure IMHO mixes up
> these two steps that aren't necessarily conditioned on each other.

My only problem with that on Debian is this build-within-a-build in cashutil 
branch. I need to be able to hook cashutil/configure onto the end 
of ./configure in a wrapper script that passes on the --prefix and nothing 
else.

The old autogen.sh in the cashutil branch does this nicely now. Take a look at 
r11860.

> Therefore I strongly proposed (on IRC) and propose to remove that automatic
> calling convention and instead have each developer call this in two steps
> from now on.

Unfortunately, I would prefer a wrapper script - of any kind - that at least 
ties the two configure scripts together. It makes no sense to allow 
--enable-cashutil if the cashutil configure is not run.

I might be able to tack it onto configure using an internal variable that 
executes a string just before AC_OUTPUT. I'll try that later. In the 
meantime, please take a look at the cashutil branch and see if you can follow 
what I'm doing and how to move to the new script.

> The point is that autogen.sh has really zero command options, whereas
> configure has plenty of them. Passing the configure options to autogen IMHO
> messes up the understanding which options should be passed to where.

Fine, it's the wrapper I need - autogen.sh was the obvious candidate with the 
old arrangement and now if it isn't being passed --prefix then there's no 
point in using autogen.sh as the wrapper - but I would like something else to 
replace that functionality.

> * As for undefined macros and potentially the wrong autotools versions: The
> previous autogen.sh script totally blurred up the actual autotool versions
> that will be called.

Maybe, but it also allowed easier customisation of specific problems like OSX.

> Have you tried to find out which part of the 
> macros/autogen.sh is actually being used at gnucash and which is not, and
> which automake/aclocal/whatever version will really be called? The new
> autogen.sh will directly put you, the developer, at the decision line. The
> script will call that aclocal/automake/whatever that's available under that
> name, *unless* you define AUTOMAKE=automake-1.2.3 before calling that
> script. Please look into the script.

I have and it did not allow me to build gnucash on a system that had built it 
under the old script. I had to actually uninstall certain auto tools which 
has meant a MAJOR PITA for me because I am now completely unable to update 
gnucash1.8 because the auto tools are too recent. I cannot build 1.8 with the 
auto tools that G2 now needs.

IMHO, that is *not* an improvement to the overall situation.

> So if you need to use some non-default 
> versions of the autotools on darwin, simply define the appropriate env
> variables before calling autogen.sh.

Just like the 'sed' patch I've committed to trunk today, OSX needs to always 
use the GNU versions and things will break when the BSD versions get in the 
way. Unfortunately, OSX insists on calling the BSD version unless you 
*specifically* call the GNU version - it doesn't always respect GNU 
conventions of environment variables, you appear to have to hardcode these 
things sometimes.

We've even got to the stage now that gnucash is advising OSX users to *modify 
their PATH*! That's the bad old days of MS-DOS and Windows 3.1!!!

Please don't say we're going back to autoexec.bat and config.sys!!!
:-)

Peter knows OSX better than I do, but personally I find it irksome that 
building gnucash on OSX requires hacks like changing ~/.bashrc and 
uninstalling packages that worked previously.

-- 

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/20051106/cda5316d/attachment.bin