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/
pgp269tkxQp3e.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
