Matt Armstrong <[EMAIL PROTECTED]> writes:
> How would people feel if I moved gnucash to automake? Has anyone
> here had bad experiences with it? In the past I've used it for
> smaller projects with good results. I've already begun trial work
> converting gnucash's make system over to automake and am so far
> quite happy with the experience. Whenever I run into a problem, I
> dig around and find that the automake folks have dealt with and
> solved the problem for me!
Depending on how you do it, this would probably be fine with me. The
only reason I've never attempted this is that I don't know much about
automake (just enough to patch up a few broken things in other
projects here and there). In theory, it sounds like a good idea as
long as it's still flexible enough to do what we need. Worst case, we
should still be able to drop down to raw shell scripting if we have
to.
I've also sent my big patch to Linas, so expect to see it soon. He'll
probably post my summary of changes when he adds the patch, but if
not, I'll re-post the summary here. Once that's incorporated, I don't
plan any major configure changes in the short term, so it'd be a
reasonable time for you to start monkeying around.
> I'll mention now that a switch to automake makes sense only in the
> context of my mail earlier this week. Namely, that we move to a
> system where the gnome/motif/qt decision happens at ./configure
> time, not make time. The motivation behind this is early detection
> of build problems, thereby reducing gnucash compilation problems.
Did you determine that we couldn't keep support for building both at
the same time, or did you just end up suggesting that we'd have to
just run two configures in separate directories -- which you had said
would be pretty easy to do given the way automake handles multiple
architectures (am I recalling all this right?)?
> Assuming the above, we have a choice: (a) change the existing
> Makefile.in's to work in the above manner or (b) use automake to
> make the job easier.
If you're going to be changing a bunch of things anyway, going to
automake is probably a good idea since you're willing to do the work.
(In theory, though, I still like the idea of cons, but it's probably
not practical here, doesn't address the same range of issues (it's
just what *make* should have been), doesn't have the same development
force behind it, and we don't want to add yet another dependency).
> Anyway, the good things:
You don't have to convince me, at least. It seems like a good tool if
it'll do what we want. I stands to potentially reduce the amount of
stuff we have to
> - Another package for maintainers to install. But end users who just
> want to compile the package don't need automake.
This isn't a big deal as far as I'm concerned.
> - Current versions have a dependency mechanism that requires that gcc
> be used by the person updating dependencies. (it is otherwise
> automatic)
Do you mean that it circumvents the automatic compile-time
determination of dependencies. If so, I don't like that.
> - Forces a model where separate build directories are used to build
> for different toolkits. No more make time differentiation. While
> this is standard behavior for GNU packages, I don't want to rock any
> boats.
I think this addresses my previous concern. Sound's OK to me. It's
certainly more straightforward than my current contorted baroque mess.
> I'd appreciate any thoughts people had on this. If nobody raises a
> red flag, I'll continue to poke around with this. If in the end
> automake still seems like a good fit, I'll send off a patch.
Go for it. And feel free to ask me if you don't understand why some
of the things are currently done the way they are.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
