On Thu, Jul 15, 1999 at 12:07:35AM -0500, Rob Browning wrote:
> Matt Armstrong <[EMAIL PROTECTED]> writes:
>
> > So, I think I'll start over and proceed along these lines. Lemme
> > know if either (a) you are an automake guru and would like to take
> > over where I left off or (b) you have any other thoughts.
>
> Well, perhaps we should talk about this. How substantial are the
> advantages to staying with strict automake?
Its big claim to fame is as an easy way to have your Makefiles
compliant with the GNU standards (such that things like make
dist, make install, make distcheck, make clean, make
maintainerclean, etc. all work like all other GNU programs).
For GnuCash, the conversion would remove the dependency on GNU
make and gcc.
> However, we could seriously consider unbundling lib/g-wrap and just
> placing it alongside the gnucash tar file on the download sites, and
> storing it as a separate module in CVS.
Yes, this is an option.
> Then configure could be augmented to take an argument
> --with-g-wrap-src-dir=foo that tells configure where to find
> the g-wrap src dir. The default location could just be
> ../g-wrap, and the "failure to locate warning" could read
If you're implying that the gnucash configure should then
configure and install g-wrap for the user, then the problem isn't
solved.
> The only other thing we'd need to add right now is a few steps
> in the top level makefile.in that look something like this:
Makefile.in is a generated file in an automake system -- it is
generated from Makefile.am files. We could add your make rules
to a Makefile.am, but it gets to be a pain because the rules must
somehow be hooked into the existing automake rules (for dist,
clean, install, etc.). From what I can tell, this is non-trivial
and well into the "fighting with the tool" that I was talking
about. Automake really just wants a list of source files. It
doesn't handle custom stuff like this all that gracefully.
> Thoughts?
I think the options are:
(a) completely integrate g-wrap into the gnucash code (i.e. it
is no longer a separately configured package).
(b) make people install it separately.
(c) don't use automake.
I think g-wrap is small enough that making the user install it
separately is not a big problem -- especially if we make it clear
that it can even go into their home directory and don't have to
still be present after gnucash is linked. Having a big
hard-to-compile dependency (such as XmHTML) is one thing, but
g-wrap is another.
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
